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ABSTRACT 



In accordance with the invention, a method is provided for 
remotely managing a plurality of network element of a 



telecommunications network through a special communica- 
tion link including a computer internet such as a local area 
network, the world wide web or the Internet. A management 
computer is connected to an element management system 
server through a communication link including the computer 
internet At least one of the plurality of network elements is 
also coupled to the element management server through the 
computer internet and the at least one of the plurality of 
network elements is managed via communications conveyed 
through the element management server between the man- 
agement computer and the at least one network element. 
Preferably, management is facilitated by the management 
server generating an interactive web page at a client work- 
station with objects associated with management of the at 
least one network element. The interactive web page is 
transmitting from the management server through the com- 
puter internet to the management computer and displayed at 
the interactive web page at the management computer for 
management communications between the management 
computer and the network element. Objects of the interac- 
tive web page include objects associated with preferably all 
three of operation, administration and maintenance of the 
network lement. The interactive web page includes detailed 
status summary page for each network element of the 
telecommunications network, a relatively high system status 
summary of all the plurality of network elements and a list 
of all active alarms within the telecommunications network. 
The plurality of network elements each have an associated 
applications processor with a management agent application 
for interfacing the element management server with the 
network element. The application processor includes a 
maintenance application for performing maintenance of the 
network element command request are interfaced from the 
element management server through the management agent 
application to the maintenance application to selectively 
perform maintenance tasks. The element management server 
is provided with application processor specific events and 
command acknowledgments. 
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Teim 



Definition 



An abstract rcprtscstalion of a resouice that may be managed by the 
netwojk management platform. Examples inchide a network element, a 

maintenance unit, netwoik element sommary, <tatalink. 

Afimction passed by the client to the server that is used by the server to 
deliver asynchronous notifications of attribute changes, configuiation 

changes or event notificatioiis. 

A reference in the EMS Server to the callback object within the cUem. 
The reference is used by the server to intvokc the method within the 

callback object to deliver a notificatioa. 

A named set of managed objects that share the same sets of attributes, 
notifications and management operations. An example is the AP 
managed object class. 



Managed Object 



Oient Callback Function 



Callback Object Reference 



Managed Objea Class 



Managed Object Class Code 



A code that identifies a specific managed object class (uniqne to the 
system). This code is a constant (enumeration or integer definition). 



Instance Identifier An integer value that identifies a specific instance of a managed object 
and is unique within its managed objea dasa. 



Managed Object Identifier 



The combination of managed object class code and instance identifier 
defines the managed object identifier. Also abbreviated as an MOID. 



The object that provides services fbr a managed object dass. Client 
applications acquire a reference to this object (in CORBA they bind to the 
object). An example is the AP sendee object and the User Session service 

object 

A pn^jerty of a managed object. An attribute has a value 



Service Objea 



Attribute 



Attribute Code 



A code that identifies a specific attribute of a managed objea class. 



Method or Operation 



An operation or method on a managed objea performs an action. 



Notificatioa 



Information emitted by a managed oliioea relating to an evem that has 
occurred within the managed object An example is an attribute change hJc yfj ft Cj^T/o^ 



Inheritance 



The conceptual mechanism by which attributes, notifications, operations, 
and behavior are acquired by a subclass fixmi its superclass. 



User Session Each client must establish a unique session that is used to validate access 
permissions and for subsequent routing of notifications. 



Marshaling 



Containment 



Encoding and decoding an operation and its parameters into flattened 
message formats. 



A structuring relationship for managed objea instances in which the 
existence of a managed objea instance is dependent on the existence of a 
containing managed objea instance. An example is the RCS objea 
contained within the AP objea. 



ffG, 6 
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METHOD FOR COMPUTER INTERNET REMOTE 
MANAGEMENT OF A TELECOMMUNICATION 
NETWORK ELEMENT 

BACKGROUND OF THE INVENTION 

[0001] This invention generally relates to a telecommuni- 
cation network and more particularly to managing network 
elements of the telecommunications network. 

[0002] Network management systems in which a manage- 
ment computer, or work station, runs a management com- 
puter program, or management application, to manage a set 
of management agent computer programs, or management 
agents, associated with a corresponding set of network 
elements are known. Such known management systems 
employ a communication protocol that employs a manage- 
ment information base for each network that defines the 
interface between the management application and the net- 
work element. These management systems are implemented 
only at the individual network elements and have not been 
successfully employed for large scale management of a 
telecommunications network. 

SUMMARY OF THE INVENTION 

[0003] In accordance with the invention, a method is 
provided for remotely managing a network element of a 
telecommunications network through a special communica- 
tion link including a computer internet. A management 
computer is connected to an element management system 
server through a communication link including a computer 
internet. At least one of the plurality of network elements is 
also coupled to the element management server through the 
computer internet and the at least one of the plurality of 
network elements is managed via communications conveyed 
through the element management server between the man- 
agement computer and the at least one network element. 

[0004] Preferably, management is facilitated by the man- 
agement server generating an interactive web page at a client 
workstation with objects associated with management of the 
at least one network element. The interactive web page is 
transmitting from the management server through the com- 
puter internet to the management computer and displayed at 
the interactive web page at the management computer for 
management communications between the management 
computer and the network element. Objects of the interac- 
tive web page include objects associated with preferably all 
three of operation, administration and maintenance of the 
network element. 

[0005] In an embodiment, the interactive web page 
includes a detailed status summary page for each network 
element of the telecommunications network, a relatively 
high system status simimary of all the plurality of network 
elements and a list of all active alarms within the telecom- 
munications network. 

[0006] The plurality of network elements each have an 
associated applications processor with a management agent 
application for interfacing the element management server 
with the network element. The application processor 
includes a maintenance application for performing mainte- 
nance of the network element command request are inter- 
faced from the element management server through the 
management agent application to the maintenance applica- 



tion to selectively perform maintenance tasks. The element 
management server is provided with application processor 
specific events and command acknowledgments. 

[0007] Preferably, the computer internet is the world wide 
web, or Internet, connections and communications are 
achieved through operating world wide web based JAVA 
applications at the management computer and the element 
management server. Alternatively, the computer internet is a 
local area network. In this way, multiple management com- 
puters at different remote locations are capable of accessing 
any and all of the network elements of the telecommunica- 
tions network. Multiple commands simultaneously received 
from a plurality of different management computers arc 
queued and the multiple conmiands are responded to by 
sending responses to only the appropriate ones of the 
different management computers that originated the corre- 
sponding commands. Connection of the management com- 
puters to the special element management server is prefer- 
ably enabled only in response to entry of a correct password 
at the management computer. Preferably, the password is 
encrypted prior to being sent to the element management 
server. 

[0008] Thus, the invention also includes the concept of 
managing all of the plurality of network elements from a 
plurality of different remote management computers by 
performing the steps of selectively rumaing a management 
application at a plurality of different work station for com- 
mand, control and fault management of the network ele- 
ments, interfacing an element management server through a 
computer internet to the plurality of different work stations 
to provide distributed network element management ser- 
vices to the management application at all of the plurality of 
work stations, and interfacing the network element with the 
element management server through a management agent 
application associated with the network element for com- 
municating command acknowledgment and command 
requests through the computer internet between the network 
management server and the network element. 

[0009] Thus, a method is provided which overcomes the 
deficiencies of known network element maaagement sys- 
tems and methods that provides distributed network man- 
agement for enhanced efficiency and convenience which has 
the features needed for large scale management of a tele- 
communications system. 

[0010] Appendix A provides a definition of terms and a 
glossary of acronyms included in this application. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The forgoing advantageous features will be made 
apparent and other features of the invention wiU be 
described in the detailed description of the preferred 
embodiment that is given with reference to the several 
figures of the drawing, in which: 

[0012] FIG. lA is a functional block diagram of an 
embodiment of the network element management system in 
which the management computer, or work station, is 
employed to control, or manage, a plurality of network 
elements of a telecommunication network through a public 
switched telephone network (PSTN); 

[0013] FIG. IB is a functional block diagram of an 
embodiment of the network element management system in 
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which the managemenl computer, a work station, is 
employed to control, or manage, a plurality of network 
elements of a telecommunications network through a com- 
puter internet; 

[0014] FIG. IC is a functional block diagram of an 
embodiment of the network element management system in 
which the management computer, or work station, is 
employed to control, or manage, a plurality of network 
elements of a telecommunication network through a local 
area network; 

[0015] FIG. 2 is a functional block diagram of an element 
management system in which the management of a network 
element is accompHshed at a web enabled workstation with 
offthe-shelf components and proprietary applications; 

[0016] FIG. 3 is a functional block diagram of the major 
software of the architecture of the invention; 

[0017] FIG. 4 is a functional block diagram for the 
element management system server and a client workstation 
with an associated network clement and its associated 
simple management protocol (SNMP) agent. 

[0018] FIG, 5 is a functional block diagram showing 
element management system client configuration; 

[0019] FIG. 6 is a table of terms associated with the 
managed object model in accordance with the invention; 

[0020] FIG. 7 is a functional block diagram showing the 
derivation of application process; 

[0021] FIG. 8 is a functional block diagram of managed 
object classes and their containment relationship that may be 
used to manage to apphcation process; 

[0022] FIG. 9 is a block diagram showing a network 
element, AP, service object and the data it contains and an 
ECP managed object using a protocol other than SNMP for 
communication; 

[0023] FIGS. 10, 11, 12 and 13 show representative web 
pages in accordance with the invention; 

[0024] FIG. 14 is a functional block diagram of a network 
element, AP, software architecture; 

[0025] FIG. 15 shows element manager client application 
programming interfaces; 

[0026] FIG, 16 shows the service objeas resident on the 
server with which client applications interact; 

[0027] FIG. 17 shows the callback interfaces defined in 
the EMAPI; 

[0028] FIG. 18 shows data types defined in the EMAPI; 

[0029] FIG. 19 shows the relationship between client, 
application, specific service object, and the internal server 
representation of managed object instances; 

[0030] FIG. 20 shows fiher criteria which are vaUd for 
each event category; and 

[0031] FIG, 21 shows an EMAPI specific exception 
defined with an EMAPI exception code containing one of a 
plurality of values. 



DETAILED DESCRIPTION 
[0032] FIG. lA illustrates a system 10 in which the 
method of managing a network element 14 at a web enabled 
workstation 16 is shown. A management computer 26 asso- 
ciated with an element management system client 28 is 
connected to a network element 14 and element manage- 
ment system client 32 through a public switched telephone 
network (PSTN) 33. 

[0033] FIG. IB illustrates a system 34 in which the 
method of managing the network element 14 in a telephonic 
network at web enabled workstation 16 is shown. Network 
element 14 is connected through a telephonic computer 
network 35 to a computer internet 36. The management 
computer 26 associated with the element management sys- 
tem client 28 is connected to the element system manage- 
ment system sever 32 over a telephonic system network 34 
through the computer internet 35 and a telephonic link 38. 

[0034] FIG. IC iUustrates a system 40 in which the 
managing of the network element 14 is performed from the 
management computer 26 with the associated element man- 
agement system client 28 with the element management 
system 32 via a local area network 42. 

[0035] The method in accordance with a the invention 
enables the leveraging of off-the-shelf technology to enable 
additional client visible features, while extending to subse- 
quent releases and other projects, with Uttle to no increase to 
cost of goods. 

[0036] Referring to FIG. 2, the network element 14 is 
provided through the clement management system client 28 
and a SNMP-based element management platform. The 
method in accordance with the invention works with off- 
the-shelf components 44, 45, 46, 47, 48 and 49 and propriety 
applications 50, 52, 54, 55 and 56. The off-the-shelf tech- 
nologies include: the HTML and Java apps 44, the web 
browser 45, the web server 46, Transport Protocols [TCP/IP 
UDP/IP]47, CORBA 48, and the SNMP element manage- 
ment platform (HP Open View Network Node Manager 
[HPOVNNM]) 49, alternatively a Carnegie -Mellon Univer- 
sity (CMU) SNMP library is used, and the Transport Pro- 
tocols (TCP/IP protocol suite). 

[0037] The client executes the Client Interface and pro- 
priety applications via Web pages. Microsoft Internet 
Explorer and netscape browsers are supported as are the 
web-enabling devices for PCs and X-temainals. Through a 
Web-based graphical client interface, clients' commands 
generate HTTP requests to the element management system 
server. The server gathers information, dynamically gener- 
ates a Web page, and sends the results/output to the web 
browser for display, 

[0038] Client applications (JAVA Applets) include propri- 
etary applications such as, an active alarm list browser, a 
system alarm summary, and a network element detailed 
status display. Client applications communicate with the 
server via an object oriented interface to the element man- 
ager API (EMAPI) 55 through the distributed object request 
architecture (CORBA) 48, This interface provides a consis- 
tent interface to all managed objects in the network, and 
hides the implementation details associated with the element 
manager platform. 

[0039] The element management system server 32 
executes applications to serve information to clients via 
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CORBA middleware. CORBA will serve as the IPC for 
functions residing on the server, thereby eliminating any 
platform-specific IPC from the implementation, and provid- 
ing for distribution of functionality to multiple processors if 
needed in the future for performance. Communication 
between the element management system and the managed 
elements is via SNMP. System status is obtained through 
SNMP polling and audits, SNMP traps are used for real-time 
notifications, and SNMP sets are used for command and 
control. The element management system has no persistent 
store over a system boot, and requires a handshake with each 
network element when the element management system is 
initialized; however, it does store information for use by 
multiple clients, so it does not need to get this information 
for each request from a new client. Command and alarm 
output is displayed via the Web browser based display, as 
well as sent to an executive control processor read only 
printer. 

[0040] The network element 14 is responsible for process- 
ing event and alarm notifications to the element management 
system via SNMP, and for issuing commands for obtaining 
information from applications. A management information 
base (MIB) 56 conventions is defined for managing network 
elements in the system. The MMB 56 conventions define 
command execution, message sequencing, and audit provi- 
sions, that are used within the element management system 
architecture but are not provided for in SNMP. 

[0041] The following is a description of the functional 
block diagram shown in FIG. 3 of the software components 
of the invention. 

[0042] Element Management Server Software Compo- 
nents 

[0043] The element management system client 28 is the 
client*s interface to the element management system server 
32. It consists of the web browser 45 and the JAVA applets 
44. 

[0044] Web Browser: The web browser 45 is the inter- 
face to end client, a host for JAVA applets 44, and a 
virtual machine for JAVA execution. Netscape and MS 
Explorer are both supported (for platforms that support 
these browsers). 

[0045] JAVAApplets: JAVA Applets 44 include but are 
not limited to the following: 

[0046] System Summary Application: provides a 
hierarchical view of alarm status, summary icons for 
parent nodes, color encoding of alarm stales, and 
point/click navigation to Network Element Detailed 
Status screens; 

[0047] Network Element Detailed Status Applica- 
tion: provides a custom view of each network ele- 
ment, displays static configuration data, and main- 
tenance state of all managed objects; 

[004S] Active Alarm List Browser Application: dis- 
plays the current list of outstanding alarms in the 
system. 

[0049] The major software components of the Element 
management system server include: 

[0050] HTTP Web Server 58: processes HTTP requests 
from the element management system Client that 



retrieve and download HTML pages and Java applets 
(from the clement management system Server hard 
disk) associated with the element management system 
Client application (from the clement management sys- 
tem Server hard disk). 

[0051] Orbixd 60: lona Orbix daemon, the object 
request broker 

[0052] Orbix Naming Service 64: an Orbix process that 
services object locator requests 

[0053] Object Server 66: a single UNIX process that 
provides most of the clement management system 
server functionality. It is described in detail in later 
sections of this document. 

[0054] Active Alarm Manager 68: provides for client 
access to alarms currently active in the system and 
represents the element management system component 
of the Client Alarm List application. 

[0055] HPOV processes 70: provide the network man- 
agement system infrastructure (SNMP API, trapd, post- 
master daemon). Alternatively, the network manage- 
ment system is performed by a CMU SNMP library. 

[0056] ROP Formatter 72: translates binary message 
codes into ASCII text in accordance to ECP ROP 
formatting practices. It then directs the formatted 
ASCII output to the ROP stream. 

[0057] Command Line Inteq)reter 76: provides an 
ASCII command language interface to allow the tech- 
nician to enter commands at the element management 
system and observe results. 

[0058] LX Proxy 78: UX message interface (bridge 
between System V message queues and sockets) to an 
internal database subsystem (IDS) 79. 

[0059] INTERNAL DATABASE SUBSYSTEM (IDS) 
79: ECP Ring Database Update triggers the object 
server (through UX Proxy) when an AP is added to the 
system. 

[0060] Application Processor (AP) Components 

[0061] The following components reside on the AP 80: 

[0062] SNMP Agent 81: sends and receives messages 
between the AP and element management system infra- 
structure. It is also responsible for the throttling traps to 
prevent overloading the system. 

[0063] the internal database subsystem (IDS) 79: ECP 
Ring Database Update downloads AP configuration 
data and updates from a ECP 82. 

[0064] ECP Agent 86: processes IDS triggers, notifies 
AP appUcations of changes to their configuration data, 
and send configuration changes (events) to the event 
handler. 

[0065] Command Handler 88: Handles AP administra- 
tion command requests issued from either the GUI 
based or text based cUent interfaces. Executes a RAP 90 
to complete the administration request. Returns the 
completion information back to the element manage- 
ment system server. Keeps list of active commands in 
AP Command Table. 
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[0066] Text Command Inteqireter 92: A text based 
interface for special situations in which the GUI based 
interface presented by the element management system 
Server is not available to the client, 

[0067] Event Handler 94: The Event Handler is respon- 
sible for handling both the filtering and forwarding of 
events (alarms, notifications, state changes, configura- 
tion changes) to the element management system. 
Updates the State and Alarm Tables in NEST. 

[0068] NE Status Table 96: also known as the NEST, 
stores maintenance object state and alarm information, 
as well as the list of active commands. 

[0069] RAPs 90: The Resource Administration Process 
is an application processing interface (API) for fork- 
exec* ing a process and obtaining the results of the 
process execution 

[0070] Other platform and application software 98: 
encompasses all the entities involved in command 
execution that aren't otherwise displayed on the dia- 
gram due to the desire not to get into too much detail. 
This includes the RCC resource monitors and resource 
daemons that come into play when executing an RCC 
100 based element management system command (e.g., 
remove DSl digital switch), as well as the software 
application specific to a given resource (e.g., RCS, 
MMA, CCM. SS7). 

[0071] RCC 100: as shown it is the call to RCC 100 
APIs to generate RCC events for taking a resource out 
of service. This bubble only comes into play when 
RCC-based element management system commands 
are executed. Since this is only an overview, the case 
for non-RCC-based element management system com- 
mands (e.g., diagnose DSl) is not shown. 

[0072] AP State Monitor 104: a bridge mapping RCC 
100 events into locally understood AP 80 events. 
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[0084] Web Technology 

[0085] The World Wide Web Consortium Web Site 
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[0087] Orfali, Robert et. al. "The Essential Distributed 
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[0088] Vmoski, Steve, "distributed Object Computing 
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[0089] The Object Management Group Web Site 
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[0090] FIG. 4 shows a summary of the principle func- 
tional components on the element management system 
server and a single client workstation. A single managed 
network element 14 is shown with its associated SNMP 
Agent. A table in FIG. 4 provides a definition of terms used 
in the subsequent description. 

[0091] Element Management System Client Components 

[0092] Element management system client 28 components 
consist of web browser hosted applications that provide 
network element command and control and fault manage- 
ment. These web browser hosted applications provide a 
graphical client interface based client interface in a cross 
platform environment. The server infrastructure supports 
applications for performance and security management. 

[0093] The client interface to the server is described in the 
EMAPI 55 described in a pending patent application previ- 
ously incorporated by reference herein. The EMAPI 55 is 
implemented utilizing an industry standard object manage- 
ment group interface description language (IDL). The inter- 
faces and semantics of the EMAPI 55 enable client appli- 
cation processes to utilize this interface to provide 
management of the system. Distribution of this interface is 
achieved through use of the Common Object Request Bro- 
ker Architecture (CORBA) which provides a distributed 
object request architecture. 

[0094] Client applications utilize the EMAPI 55 to access 
service objects on the server which provide access to 
attributes of the managed objects, provide maintenance 
operations for those managed objects, and allow the client to 
register for notifications of attribute changes and event 
notifications (which typically will be command acknowl- 
edgments and command results). 

[0095] The development of client applications depends 
only on the EMAPI 55 interface specification. The use of 
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CORBA allows the clients to be distributed and imple- 
mented in a different language (such as Java) than the server 
(in C++). 

[0096] The element management system server 32 con- 
sists of a set of software components that provide an SNMP 
network management framework and distributed network 
management services to client applications. The method in 
accordance with the invention uses off-the-shelf software 
components. The off-the-shelf software components 
included in the element management system are: 

[0097] (a) HTTP Web Seiver 

[0098] (b) Netscape or Microsoft® Internet Explorer 
Web Browser 

[0099] (c) Orbix Daemon 

[0100] (d) Orbix Naming Service 

[0101] (e) HP OpenView Network Node Manager 
(HPOVNNM) or alternatively, a CMU SNMP 
library package 

[0102] The element management system server 32 soft- 
ware components that are provided by the applicant include: 

[0103] (a) object server 66 

[0104] (b) active alarm manager 120 

[0105] (c) Unix subsystem proxy 

[0106] (d) read only printer formatter 

[0107] (e) command line interpreter 

[0108] The first two components, the object server 66 and 
the active alarm manager 120, provide the bulk of the server 
functionality required to support the element management 
system client applications. The other three components 
serve important supporting roles. 

[0109] Off the Shelf Element Management System Server 
Components 

[0110] HTTP Web Server (Generally called Web Server) 

[0111] This off the shelf functionahty serves static and 
dynamic web pages to client browsers. The web server must 
provide support for HTTP 1.0 (or greater), CGI scripts and 
provide a built in API for the creation of dynamic web pages 
"on the fly". The Web server supports the following: 

[0112] CGI script execution. 

[0113] Automatic startup from init (no human interven- 
tion to start server) 

[0114] logging of page access, A log file containing the 
IP address and the URL referenced. This is used to 
examine access patterns and detect and trace access 
from unauthorized sources. 

[0115] Web page access control based on client name 
and password. The server supports basic server authen- 
tication, and can be enhanced to support SSL (Secure 
Socket Layer) if encryption of the browser to server 
connection is required. 

[0116] Secure administrator administration of web 
server including administration of the client name and 
password for access control. 



[0117] Orbix Web Server 

[0118] Part of the Orbix product. Required to support 
CORBA within a Web browser. Enables JAVA applets 
downloaded to the client to communicate via CORBA to the 
element management system Server. 

[0119] Orbix Daemon (CORBA ORB) 

[0120] The CORBA ORB represents the server side of 
CORBA and is provided by an offthe-shelf CORBA imple- 
mentation. The Common Object Request Broker Architec- 
ture (CORBA) is utilized in this architecture to provide 
inter-process and inter-processor communication between 
clients using the EMAPI 55. 

[0121] CORBA is a platform-independent and lan- 
guage-independent programming and execution envi- 
ronment for distributed objects. 

[0122] CORBA automates many common network pro- 
gramming tasks: 

[0123] object registration 

[0124] location and activation 

[0125] request multiplexing/de-multiplexing 

[0126] framing and error-handling 

[0127] parameter marshaling and de-marshaling 

[0128] operation dispatching 

[0129] Access to remote object services is transparent to 
the caller. Clients do not need to know: 

[0130] where the object is located 

[0131] its programming language 

[0132] its operating system 

[0133] any other system aspects that are not part of an 
object's interface 

[0134] Orbix Naming Service 

[0135] The Orbix Naming Service daemon provides sym- 
bolic lookup of servers on the network and is necessary to 
support the HOP protocol. 

[0136] HP Open View or Alternatively CMU SNMP 
Library 

[0137] Functional Description 

[0138] The HP OpenView Network Node Manager 
(HPOVNNM) or CMU SNMP library product provide the 
lowest -level network management inJBrastructure for deliv- 
ery of SNMP SET and GET requests and receipt of SNMP 
traps. This infrastructure will deliver GET and SET requests 
from the element management system Server to the SNMP 
agent and receive traps on the standard trap UDP port and 
forward them to the SNMP Mediator, 

[0139] Role of HP OpenView Network Node Manager 

[0140] When used in the invention, HP OpenView Net- 
work Node Manager (HPOVNNM) is used as part of the 
element management system server 32 infrastructure. While 
only a subset of the HPOVNNM runtime system will be in 
active use, the full HPOVNNM system will be installed on 
the element management system server. The following 
major components will be installed. Those pieces of 
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HPOVNNM that will be a part of the element management 
system server infrastructure arc shown in bold typeface. 

[0141] ovspmd (OpenView System Process Manage- 
ment Daemon): This process must be running to enable 
client-interface status-checking programs such as 
ovstart to work. Since this monitor does not support 
restarting terminated system processes, it will not be of 
particular use in the EM Server process management 
scheme, 

[0142] OVLicenseMgr: the license manager that con- 
trols the startup of critical HPOVNNM runtime com- 
ponents and the ovw browser application. 

[0143] ovtrapd (OpenView Trap Daemon): Receive 
incoming SNMP traps from each SNMP agent on a 
standard port and forward them to the postmaster 
daemon (see below). 

[0144] pmd (Postmaster Daemon): Serves as a general 
packet router in the HPOVNNM infrastructure. The 
pmd process receives traps from ovtrapd and forwards 
them to the element management system Object Server, 
which has registered to receive all traps. 

[0145] ovactiond: the OpenView process that manages 
the association of traps to UNIXlevel actions as defined 
through the HP OpenMew event management soft- 
ware. 

[0146] ovtopmd: the OpenView Topology Manager 
Daemon, which handles IP discovery and layout for the 
HPOVNNM topology database. 

[0147] netmon (Network Monitor): Discovers and 
monitors nodes on the network. It processes ICMP ping 
to monitor nodes, and it does simple SNMP periodic 
polling using the system grotip of MIB-2. 

[0148] snmpCollect: SNMP Collection Daemon which 
allows clients to define, via the HP OpenView Win- 
dows X-based GUI interface, SNMP MIB values that 
are to be collected periodically. It provides ways to 
define thresholds and associated actions (UNIX shell 
commands). 

[0149] ovw (OpenView Windows): The OpenView 
Windows X-based GUI provides access to map apph- 
cations, an event browser, and a MIB browser 

[0150] ovwdb (OpenView Windows Database): The 
OpenView Windows topology database manager. 

[0151] The HPOV SNMP API, a C-Ianguage interface to 
this runtime system, is provided as part of the HPOVNNM 
Developer's Kit and will be used to: 

[0152] Encode and decode SNMP packets. 

[0153] Set up and tear down SNMP trap sessions. 

[0154] The entire platform as described is installed and 
active is to support 3"* -party SNMP management applica- 
tions written specifically for HP OpenView and making use 
of the ovw map framework. These applications are incor- 
porated with minimal effort, since off-the-shelf S'^^-party 
applications use the ovwdb -based managed-object database 
rather than the CORBA-based Object Server mechanism. 



[0155] Administration 

[0156] Some administration of the HPOVNNM infrastruc- 
ture is required if used instead of a CMU SNMP library 
package. 

[0157] Initial configuration: 

[0158] Definition of the local registration files used 
by HPOVNNM to determine which processes run 
and to define the specific attributes of each of these 
processes 

[0159] Definition of the trap configuration file: this 
defines what processing (including just logging) is 
performed on each trap received by the HPOVNNM 
infrastmcture 

[0160] Inclusion of the HPOVNNM ovstart com- 
mand in the appropriate RCC initialization file for 
automatic startup of infrastructure 

[0161] Configuration of the network license manager 
used by HPOVNNM 

[0162] Ongoing maintenance 

[0163] MIB updates 

[0164] License updates to the network license man- 
ager used by HPOVNNM 

[0165] Element Management System Server Components 
in Accordance with the Invention 

[0166] Object Sever 

[0167] The object server provides a way for client appli- 
cations to receive information about network elements and 
other associated managed objects and to issue commands 
that are executed on the network element. To accomplish 
these functions, the object server provides the following 
services: (1) client session registration, (2) event distribution 
and screening, (3) command management, (4) SNMP 
mediation, and (5) services specific to each managed object 
class. 

[0168] The object server is implemented as a single - 
threaded process tising a central event queue. However, the 
architecture does not dictate this implementation. The archi- 
tecture docs require that the implementation be platform and 
operating system neutral, and the concern is that a multi- 
threaded approach would have operating system dependen- 
cies. The sub-components that comprise the object server 
could be implemented as separate processes. An example of 
the latter approach is the decision to implement a second 
major server component, the active alarm manager, as a 
separate process. As the element management system infra- 
structure evolves, other components that are currently part of 
the object server might be implemented as separate pro- 
cesses, if necessary and feasible. 

[0169] Various forms of inter-process communication may 
be used to communicate between these components, but the 
method recommended by this architecture is to use CORBA 
to remove platform-specific IPC from the implementation, 
and to provide for distribution of functionality to multiple 
processors if necessary for performance optimization, 

[0170] As shown in FIG. 3, the object server consists of 
the following set of components, each of which supports a 
particular service: 
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[0171] Client Session Manager 130 maintains a list 
of active client sessions and audits for sessions that 
have ternoinaled without notifying the manager. 

[0172] Event Distributor 140 provides event routing 
and distribution. Events include SNMP Traps 
(received via the SNMP Mediator) from network 
elements, commands, command acknowledgments, 
command responses, and events generated within the 
element management system. Clients of the Event 
distributor register a filter with the Event Distributor 
to request delivery (via a callback function) of 
Events matching the filter. 

[0173] Event Screener 150 is for use by the Object 
Server only, and supports screening events before 
they are seen by the event distributor for purposes of 
open-ended event correlation. 

[0174] Element Management System Command 
Handler 155 tracks active commands and releases 
resources when the commands complete. The ele- 
ment management system Conunand Handler also 
coordinates the execution of commands within the 
element management system. 

[0175] SNMP Mediator 160 provides translation 
between the MIB ASN.l format and the managed 
object notation used in this architecture. The SNMP 
Mediator also provides polling services for the 
SNMP Service Objects, and conversion of managed 
object commands (e.g. remove, restore) into appro- 
priate SNMP set commands, 

[0176] Managed Objects: As shown in FIG. 3, each 
object that represents a network element or mainte- 
nance unit in a network element utilizing SNMP for 
its protocol (e.g. AP, DSl, EIN, LAN) is represented 
as a "SnmpMO" class object 170. A single instance 
of an object is used for all instances of that objects 
class in the system. For example, the AP service 
object provides attributes and methods for all 
instances of AP processors in the system. In addition 
to SnmpMOs, the architecture supports "Logical 
managed objects** that represent managed objects 
that aren't directly tied to a network element or 
maintenance unit. An example would be a "System" 
managed object class that would provide system 
level status and commands. 

[0177] Active Alarm Manager 

[0178] The active alarm manager 120 provides for client 
access to alarms currently active in the system and repre- 
sents the element management system component of the 
client alarm list application. There are two communicating 
entities: the AP Active Alarm Table (AAf) managed object 
(of class ApActiveAlarms) residing in the Object Server; 
and the Active Alarm Manager (AAM), a separate UNIX 
system process on the element management system that 
provides access (as defined by class AlarmManager) to 
client applications. The AAM is implemented as a separate 
system process on the element management system to avoid 
blocking the execution of the object server when potentially 
large volumes of alarm data must be delivered by the AAM 
(e.g., at client application startup. Since the AAT and AAM 
communicate across process boundaries, all interfaces 



between them are defined in IDL. Similarly, all interfaces 
offered by the AAM to client applications are defined in 
IDL. 

[0179] Alarms for all APs are represented in the AAT 
managed object, such that there is an alarm record for every 
class of maintenance unit that has an alarm currently active 
in an AP. Additional managed objects are introduced in the 
object server to track alarms in other maintenance units 
related to the AP (e.g. ApFramcActiveAlarms) or in another 
network element 14. As with the AAT, however, the alarms 
tracked by these managed objects will be reported to client 
applications via the AAM process. 

[0180] The AAM system process contains a table of active 
alarm records which mirrors that of the AAT managed 
object. At initialization, the AAM registers with the AAT 
managed object for delivery of current alarm records and 
notifications of subsequent updates. Multiple clients can 
register alarm filters and callbacks for delivery of alarm 
records that match specified filter criteria. Client applica- 
tions can change or cancel their specified filter criteria. 

[0181] UX Proxy 

[0182] Provides UX messaging interface to the IDS 79 to 
receive and process IDS triggers. A trigger is needed to 
notify the element management system when an AP is added 
to or deleted from the system. The element management 
system then polls the AP for its equipage data. 

[0183] ROP Formatter 

[0184] Formats the events in a format consistent with the 
ECP ROP formatting requirements, and sends the formatted 
event to the ECP for logging and printing at the ECP ROP. 

[0185] This component is a client that resides on the 
element management system server and provides the fol- 
lowing functionalities: 

[0186] Registers with the Event Distributor for all 
events 

[0187] Utilizes the locale text formatting services to 
format the raw event as a TI/OP message 

[0188] Formats the events in a format consistent with 
the ECP ROP formatting requirements 

[0189] Includes in the message the appropriate alarm 
indication 

[0190] Sends the formatted event to the ECP for logging 
and printing at the ECP ROP 

[0191] Utilizes a new message class at the ECP for 
reports 

[0192] This mechanism will rely on a single message type 
for forwarding all element management system-generated 
TI/OP messages. The current interface from a mobile switch 
center (MSC) ECP ROP supports specifying Alarm Level 
(MAN, INFO, CRIT, MAJ, MIN). 

[0193] Command Line Interpreter 

[0194] The command line interpreter provides an ASCII 
command language to allow the technician to enter com- 
mands and observe the command results. The input com- 
mand syntax is the same PDS format used by a proprietary 
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system. Command reports are also formatted in the same 
syntax as the existing proprietary system. 

[0195] Provides ASCII based input language access to 
all commands for network elements (and their mainte- 
nance units) supported by the element management 
system. 

[0196] Provides an acknowledgment to the input com- 
mand to indicate the disposition of the command. 

[0197] Allows for multiple commands to be outstanding 
at one time 

[0198] Provides command sequence numbers to corre- 
late acknowledgments and responses with commands 

[0199] Provides a final report indication for command 
responses. 

[0200] Infrastructure and Application Specific Compo- 
nents 

[0201] The architecture contains components that provide 
a general infrastructure for network management and com- 
ponents that are application specific. This section lists the 
components from FIG. 4 in infrastructure and application 
specific categories. Some components consist of infrastruc- 
ture and application specific code (e.g. command line inter- 
preter) and are noted as such. 

[0202] The following components are considered to be 
infrastructure related: 

[0203] Object Server 

[0204] Client Session Manager 

[0205] Event DisU'ibutor and Screener 

[0206] element management system Command Han- 
dler 

[0207] SNMP Mediator 

[0208] Managed Object Base Classes (ManagedOb- 
ject, NEMO, SnmpMO. SnmpNE, see FIG. 7). 

[0209] UX Proxy 

[0210] Active Alarm Manager 

[0211] Client Active Alarm Browser Application 

[0212] Client System Alarm Summary Application 

[0213] Client Network Element Detailed Status Appli- 
cation 

[0214] ROP Formatter 

[0215] Command Line Interpreter. Portions of these 
components are specific to the application, e.g., the 
screen contents and layout will vary depending on the 
particular traits of the application managed. 

[0216] The following components are considered to be 
application ^ecific: 

[0217] Commands and reports for the network element 

[0218] Application-specific Service Objects of type 
Managed Object, SnmpMO, SnmpNE 



[0219] Managed Object Model 

[0220] In this architecture, all resources and elements that 
can be managed are represented in the system as a managed 
object. Each managed object provides attributes, methods 
and notifications that are used by client applications to 
manage the object. In order to describe the managed object 
model Tised by this architecture, the following terms are 
defined and used in subsequent descriptions. 

[0221] All instances of a type of managed object share 
definition of attributes, operations, notifications and behav- 
ior, but will have attribute values that are unique for each 
instance of managed object. This approach allows common 
behaviors for managed objects to be defined in base classes, 
and for specialized behavior to be placed in the managed 
object class for that specific type of managed object (while 
inheriting the common behavior and attributes of the base 
class). More specialized forms of managed object classes 
can be developed by subclassing existing managed object 
classes, providing for reuse of existing classes. Subclasses 
will often add attributes, extend or restrict ranges of existing 
attributes, and add or restrict operations and notifications. 
This concept helps to encapsulate rules regarding the behav- 
ior of managed objects within the managed object class. This 
prevents the common practice of replicating this function- 
ality (often in varying ways) in the different applications that 
provide management for the element. FIG. 7 shows an 
example of how this approach can be used to define some of 
the managed objects. It also shows how it could be used to 
derive specific types of AP naanaged objects. Note that this 
is only an example to demonstrate the concepts described 
above. 

[0222] For SNMP based managed objects, the definition of 
the managed object and most of the managed object* s 
attributes can be derived from the definition of the MIB 55 
(generated by a tool that parses the MIB). Also, most of the 
code necessary for translation between the MIB ASN.l 
format and the EMAPI 55 object notation (performed in the 
SNMP Mediator) can also be derived from the definition of 
the MIB 55. Automation of this translation will reduce 
maintenance of the system and will reduce development of 
new managed objects when new network elements arc added 
to the system. 

[0223] The client interface to the services and the man- 
aged object attributes and methods is described in the 
EMAPI 55. The EMAPI 55 and managed object notation 
provide a consistent model of all managed objects in the 
network, hiding the implementation details associated with 
the element manager platform from client applications (for 
example, clients do not need to know whether the underlying 
protocol to the network element is SNMP, CMIP or a 
proprietary interface). Managed object specific logic is 
encapsulated within the managed object instead of scattered 
throughout various applications, thus simplifying client 
application development. 
[0224] Managed Object Notation 

[0225] A distinction is made in this model between the 
actual objects present in the server to provide services for a 
class of managed objects and the specific instances of those 
managed objects (and their attributes). Instead of creating 
object instances for all managed objects in the system which 
can become prohibitive on large element management sys- 
tems where network elements contain a large number of 
managed objects, a single service object is created to provide 
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services for a class of managed objects. Specific managed 
object instances and their attributes are referenced by use of 
a set of object class identifiers and attribute codes. The 
definition of these managed object class identifiers and 
attribute codes is part of the interface definition between all 
service objects and their clients. 

[0226] Managed Object Identifiers 

[0227] A specific instance of a managed object is refer- 
enced using its object identifier which consists of the object 
class code and an instance identifier. The object class code 
is a static enumeration or constant, and the instance identifier 
is an integer value (defined at run time based on configu- 
ration) that is unique to the object class. Although the 
instance identifier is unique to the managed object class, it 
is not the same as the logical number for that instance. Each 
managed object class provides methods for translating 
between the instance ID and an appropriate set of network 
element and unit identifiers. 

[0228] For example, AP network elements are referenced 
by logical number in the system (e.g. 1 to n). The number of 
Aps in the system is not fixed at a specific number (such as 
8) but will be based on the equipage information found in a 
database. Each AP also can have some number of application 
virtual machines, each identified by a logical number (e.g., 
RCS 1). 

[0229] A specific instance of an application managed 
object is referenced by calling a lookup function in the 
application's service object to convert the AP network 
element instance identifier and application key into its 
associated instance ID. The combination of these two values 
in the object identifier uniquely identifies a specific managed 
object instance. 

[0230] In many cases, the use of a service object for a class 
of managed objects will take the place of the object class 
code. For example, the AP object class code is not specified 
by a client when requests are made through the AP service 
object. Conversely, the AP object class code would be 
present in any events sent to a client so that the client can 
identify the specific managed object instance that generated 
the event. 

[0231] Attribute Codes 

[0232] Each managed object contains a set of attributes 
specific to that instance of that managed object class. These 
attributes describe various maintenance, operational, con- 
figuration and measurement information about the managed 
object. Each attribute is defined with an attribute code that 
is local to the name space of the managed object to which it 
belongs. For example, the AP managed object class will 
have a State attribute (as will the RCS managed object 
class). Each attribute code is unique to the managed object 
class to which it belongs. 

[0233] Attribute Value Definitions 

[0234] The type definition for any attribute value that is 
not of a basic "primitive" type (for example, short or octet) 
and is used between the clients and the server must be 
defined in the IDL. The scope of these definitions may be 
limited to the managed object that uses them, or may be at 
a higher system level (for example, alarm level definitions 
would be at a system level). 



[0235] Adding New Managed Objects 

[0236] When adding new types of managed objects in the 
system, a choice must be made to create a new type of 
managed object service class, or to use an existing service 
class and provide the ability to distinguish between different 
versions or types of managed objects in that class. The 
decision to use a new class or extend an existing class will 
depend on how similar the new type or version of managed 
object is to the existing managed object. When using a 
common service class, an attribute of a that class could be 
used to provide discrimination between various versions/ 
types of the same managed object. If a new managed object 
type is created, any common attributes and functionality 
with other similar managed object classes should be placed 
in a common base class to reduce maintenance. To summa- 
rize the guidelines: 
[0237] Create a New Managed Object for new mainte- 
nance unit types that are unique to the system, 

[0238] Subclass an existing Managed Object (or move 
common functionality to a base class if it doesn't exist) 
for new maintenance unit types that provide common 
existing attributes. Note that this will still result in a 
new managed object type. An example of this is the 
Ethernet interfaces on the AP. They both provide com- 
mon Ethernet functionality but there is an ethemet 
interface node (EDV) and a LAN managed object. 

[0239] Use version attributes for different versions of 
the same managed object. Support both hardware ver- 
sion and finnware revision attributes is needed. 

[0240] When adding new AP processors that support addi- 
tional functionality (examples of this may be IS -634 appli- 
cations) new types of managed objects will be defined to 
manage the new types of objects within that type of AP. If 
all AP processors are capable of hosting the addiUonal 
hardware and software entities (for example, in later releases 
an AP hosting RCS virtual machines could also have SS7 
hardware and host IS -634 functionality), then a MIB sup- 
porting the superset of possible managed objects must be 
constructed and made available for compilation into element 
management system runtime processes. This approach 
makes use of automatic code generation, and is intended to 
save time when adding new objects to the element manage- 
ment system. At the element management system, additional 
service objects must be created to support management of 
the instances of the new classes of managed objects (e.g. 
MMA). 

[0241] Portability 

[0242] The development of this architecture must ensure 
portability of the client and server components. This can be 
accomplished in several ways. Machine and operating sys- 
tem (OS) dependent code should be hidden as much as 
possible (especially when there are multiple interfaces to it 
within the server) by placing it within wrapper libraries. For 
example, the Element management system Logger class will 
provide object-oriented wrappers for all existing propriety 
UX logging services (UX_,ELOG, UX_DLOG. UX_PLOG 
and UX_ALOG). This allows for platform re targe tting by 
changing the implementation of the machine/OS dependent 
libraries with no impact on the calling functions or objects. 
Interprocess communication will make use of industry stan- 
dard software such as CORBA which is available on most 
machine and OS platforms. 
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[0243] Object Server CompOQenls 

[0244] This section describes the major components of the 
Object Server in detail. Each of the components may be 
represented as the element management system, processes 
or classes but are treated as general components in this 
section. Note that many of the descriptions provide general 
examples (not AP specific) since most of the components 
provide an infrastructure that is intended to support the 
migration of all OA&M for additional applications. 

[0245] Client Session Manager 

[0246] The Client Session Manager will maintain a list of 
active client sessions and applications. It will periodically 
audit that list to detect sessions that have gone away without 
explicit termination (e.g., loss of connection). 

[0247] The following functionality will be provided: 

[0248] Interface to clients for starting a session 

[0249] Creating a unique session identifier 

[0250] In the fixture, validate client security and 
permissions (see earlier section, "Security", for a 
more detailed discussion) 

[0251] Interface to clients for manually ending a session 

[0252] Interface to clients for periodic check-in (heart- 
beat) 

[0253] Interface to other server components for regis- 
tering interest in notifications of session/application 
termination. The components that have such an interest 
are: 

[0254] The Event Distributor, which is interested in 
all such terminations 

[0255] Managed Object Service Classes, which are 
interested only in specific client session/applications, 

[0256] Periodic audit of active sessions/applications to 
see if any session/application has failed to check in 
recently. Sessions/applications that have failed to check 
in within a reasonable (to be determined in design) 
amount of time will be removed from the session 
manager's active session/application list 

[0257] Notification to registered entities when a ses- 
sion/application has been ended via the callback noti- 
fication interface described above. 

[0258] Event Distributor and Screener 

[0259] The Event Distributor is responsible for filtering 
and routing of all events in the system. A client that wishes 
to be notified upon the occurrence of one or more events 
(other than attribute-change notifications) registers a filter 
with the Event Distributor specifying criteria to be matched 
against whenever an event occurs. Examples of clients 
include the Summary Alarm/Status Manager, ROP Format- 
ter, Managed Objects, and clients issuing manual mainte- 
nance requests. No formatting of events is performed within 
the Event Distributor — this is left to the application. Events 
are typically generated as a result of a trap from an SNMP 
agent, but can also be generated by element management 
system components on the same machine, or even by other 
legacy network elements. The Event Distributor may be 
implemented as a set of objects within the Object Server. 



[0260] The Event Screener supports screening of events 
before they are seen by the Event Distributor for the purpose 
of simple, open-ended event correlation. The Event Screener 
supports the same interface (although not available to cli- 
ents) as the Event Distributor, but is only for use within the 
Object Server. 

[0261] The following subsections show the functionality 
provided by the Event Screener and Event Distributor 

[0262] Client Registration and Filtering 

[0263] Provide an IDL interface (Event Distributor 
Only) for registering filters based on the following: 

[0264] Session and Application ID 

[0265] Callback object, used to deliver events to the 
interested registrant. 

[0266] Filter object containing a specification 
describing events to be delivered to the client. This 
filter allows for a limited set of parameters that 
provides for specification of a set of event attributes 
that may be combined to limit the set of events. 
Specific values for event attributes can be given or a 
special don't-care value that can be used to ignore 
the attribute. 

[0267] The event filter will contain the fields in the list 
below. Note that not all these fields must be set; those that 
do not matter can be marked don't-care as described above. 

[0268] Event Category 

[0269] Network Element instance ID and class code 

[0270] Network Element alarm level 

[0271] Maintenance Unit instance ID and class code 

[0272] Maintenance Unit alarm level 

[0273] Command ID (client session ID and command 
sequence number) 

[0274] Provide an IDL interface for clients (Event Dis- 
tributor only) and other Object Server components to 
explicitly cancel a specific filter. 

[0275] Provide a means for Object Server components 
to remove all filters associated with a specific session 
and application. 

[0276] Provide an efficient method to store client reg- 
istrations and filter criteria and an efficient method to 
examine these filter criteria on incoming traps. 

[0277] Event Receipt 

[0278] The Event Screener receives events from the 
SNMP Mediator (which receives traps from SNMP 
agents and translates them into EMAPI 55 event head- 
ers) 

[0279] The Event Distributor receives events from the 
Event Screener and other Object Server Service 
Objects. 

[0280] Match an incoming event header against each 
stored event filter. The event header will contain fields 
that match those of the event filter (given above). In 
addition, the event header will contain: 
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[0281] A time stamp indicating when the event was 
generated 

[0282] Provide delivery of traps to clients using the 
client-supplied callback function (for events that match 
their supplied filter criteria) 

[0283] The Event Distributor will play no role in event 
throttling: throttling vidll occur at the SNMP agent. 

[0284] Auditing: 

[0285] Support cleanup of the filter list, through audits 
performed by other Object Server components. This support 
is provided through the interfaces described above or via 
internal callback mechanisms. For example, when the Client 
Session Manager removes a session and/or application from 
its internal structures, it notifies the Event Distributor via a 
callback, at which point the Event Distributor removes all 
filters associated with the session and/or application. 

[0286] Filters associated with commands need to be 
cleaned up under several circumstances: 

[0287] When the final report indication is seen in a 
command event 

[0288] When the trap containing the final report 
indication is lost 

[0289] The Event Distributor will receive a notification 
when either of the above circumstances are detected, at 
which point the filter matching the affected command or 
commands will be removed. 

[0290] Command Handler 

[0291] Because various resources are utilized within the 
element management system server to process managed 
object commands, the Command Handler must track active 
commands and release resources when the commands are 
completed. Active commands are modeled as another class 
of managed objects within this system, and the Command 
Handler represents the service object for all instances of 
active commands. The Command Handler provides the 
centralized tracking and management of these commands. 
Since command responses are delivered via unreliable 
SNMP traps, an audit of command activity between the 
network element and the Command Handler must be per- 
formed. 

[0292] Command Block 

[0293] Command blocks will contain at least the follow- 
ing fields: 

[0294] Command Sequence Number 
[0295] Session Identifier 

[0296] Object Instance Identifier (for example, which 
AP? Or which DSl?) 

[0297] Command Type 

[0298] Command Qualifier (optional) 

[0299] Some commands may require additional argu- 
ments. Since each command block is defined separately, it is 
simple to implement additional arguments. 



[0300] Command Responses/Acknowledgments 

[0301] Each agent must generate an acknowledgment trap 
in response to each command request containing the origi- 
nating session identifier and command sequence number 
along with an acknowledgment value indicating whether the 
command request is invalid or could not be processed, 
processed as requested with no further response, or in 
progress with addQtional response pending. In the latter case, 
one or more command response traps will be generated 
which also contain originating session id and command 
sequence number, along with a response sequence number 
and final report indication. Since UDP messages may be 
received out-of-sequence, the response sequence number 
may be used by a client application to reorder multiple 
responses for the same command. 

[0302] Command Filter Cleanup 

[0303] The final report indication wiU be used by client 
applications to note when a command-initiated action is 
completed, and will also be used by the server to automati- 
cally de-register event filters associated with that command. 
Each agent will support an active command table listing the 
session IDS and command sequence number of all com- 
mands in -progress. This table will be audited periodically by 
the server to initiate filter removal when final report traps are 
lost. 

[0304] SNMP Mediator 

[0305] This functionality provides translation between the 
EMAPI 55 class and attributes and the IP addresses and 
object identifiers of the SNMP MIB. It is also responsible for 
formulating appropriate SNMP requests (SNMP SET 
requests for maintenance requests, SNMP GET requests for 
polling and auditing) and routing responses back to the 
requestei(s). It queues SNMP requests and ensures that no 
single Network Element SNMP Agent is overwhelmed by a 
burst of requests. Note that there is no client access to this 
component; it exists solely for internal use within the Object 
Server. 

[0306] SNMP to EMAPI 55 Translation 

[0307] This functionality will perform translations 
between the EMAPI 55 Object Class, Instance Qass and 
Attribute Code notation and the SNMP IP Address, SNMP 
MIB Object Identifier (OID) and zero or more SNMP 
variable bindings. It may be implemented as a set of objects 
and methods within the Object Server. 

[0308] The types of translations this service must perform 
are: 

[0309] EMAPI 55 Command object to SNMP Com- 
mand Block * EMAPI 55 Poll-Request object to SNMP 
Get * EMAPI 55 Instance ID/Class Code to SNMP IP 
Address * SNMP Get Response to EMAPI 55 Poll- 
Response object * SNMP Trap to EMAPI 55 Event 
Header * SNMP IP Address to EMAPI 55 Instance 
ID/Class Code 

[0310] Object Server Interface 

[0311] Provide an interface to managed object classes in 
the object server to support: 

[0312] Auditing: the periodic polling of configuration 
data and persistent attributes (persistent in element 
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management system memory) that the Object Server 
tries to keep on the server at all times (these attributes 
are stored in memory for \ise by mtiltiple clients, and 
are not saved over a reboot of the element management 
system). 

[0313] Polling: the periodic polling of attributes that are 
requested by one or more EM Clients. 

[0314] One-Time Status Requests: a single request for 
an attribute or attributes. 

[0315] Command Execution: issuing commands using 
SNMP SET requests. 

[0316] SISTMP Interface 

[0317] The SNMP Mediator handles all interfacing with 
SNMP agents on network elements. The SNMP interface 
consists of Attribute PoUing, Configuration Auditing, Com- 
mand Execution, SNMP Retry Mechanism, and Trap Deliv- 
ery. Attribute polling 

[0318] Use the HPOV SNMP API or the CMU SNMP 
library to establish an SNMP session to each AP agent 

[0319] Use the EMAPI 55 to SNMP Translation com- 
ponent to translate between EMAPI 55 notation and the 
appropriate SNMP get request 

[0320] Translate the response to an SNMP get request to 
EMAPI 55 notation and route it back to the associated 
managed object, which then checks for and propagates 
only those values which have actually changed 

[0321] Provide control over the number of outstanding 
get and set requests to an agent. This is necessary to 
prevent overloading the socket at the agent. 

[0322] Configuration Auditing 

[0323] AP equipage is maintained via recent change. Con- 
figuration information for sub-network-element level com- 
ponents is maintained by each AP agent. When more than 
one managed object instance may be associated with an AP 
(e.g. RCS), the respective managed object is defined by a 
MIB table which is indexed by one or more configuration 
attributes (e.g. cell number). Associated with each table is 
another MIB object identifying the current number of table 
entries (the table count). Configuration information for any 
table may be retrieved by sending a GET request to the agent 
for the table count, and one or more GET-BULK requests to 
retrieve index information (also known as keys) for all valid 
rows in the table. The SNMP Mediator will perform a 
periodic audit of each table in this manner to report current 
configuration information to each associated managed 
object. 

[0324] Command Execution 

[0325] The SNMP Mediator wiU use the EMAPI 55 to 
SNMP Translation component to translate from EMAPI 55 
commands into the appropriate MIB command block set- 
tings. The SNMP Mediator will translate EMAPI 55 com- 
mands into the appropriate MIB command block and issue 
an SNMP SET. 

[0326] Command Oueing 

[0327] Because SNMP requests are sent via UDP and may 
be received by an agent out of sequence, a command 
request/response convention between manager and agent 



will be utilized to insure that an agent will respond only once 
to a single command (i.e. SET operation) regardless of the 
number of retries which may be generated. The manager will 
maintain a separate command SET queue for each network 
element. The size of the command SET queue per network 
element is preferably tunable. Only one SET request for any 
given network element will be pending at any one time. That 
is, a command protocol data unit (PDU) will not be sent to 
the associated agent until the SET response from the previ- 
ous command is received. Once the SET response has been 
received, other commands are initiated and sent to the 
associated agent. Each PDU contains a monotonically 
increasing request id, which will be examined by the agent 
on all SET requests. If the id is greater than the last 
processed, the PDU is presumed to contain a new request 
and will be acted on accordingly. If the request id is equal 
to the last processed, the agent will assume the duplicate 
packet is the result of a retry, and will return the response last 
generated. If the id is less than that last processed, it is 
presumed to be a duplicate packet for a command to which 
the manager must have already received a response (or 
timeout), so the packet is ignored. 

[0328] Failure HandUng 

[0329] When the SNMP Mediator receives a SET request 
from a managed object for delivery to a network element 
that is known to be not responding, the request will still be 
processed as received. If an associated PDU can not be sent, 
a negative acknowledgment will be generated locally, and 
returned to the originating cUent via the event distributor. 

[0330] SNMP Retry Mechanism 

[0331] Since SNMP relies on UDP as the underlying 
transport protocol, SNMP GET, GET-BULK, and SET 
operations can be lost. To recover from losses, the SNMP 
Mediator will use a mechanism for retrying SNMP transac- 
tions that will be consistent for all GET, GET-BULK and 
SET operations and will conform to the interface prescribed 
by the HPOVNNM SNMP library or the CMU SNMP 
library. For further information, see the reference to 
HPOVNNM or CMU SNMP library, previously incorpo- 
rated by reference herein. Apredefined maximum number of 
retries may be attempted for each request. There is a tunable 
timeout that is logarithmically increasing (defaults to a 
maximum retry delay of 12 seconds per request is sug- 
gested). If a response for any request is not received after the 
maximum number of retries, each of the managed objects 
associated with this network element is notified of the loss 
of communication and a local event is generated, resulting 
in an alarmed output message being delivered to the ECP 
ROP. State values in the internal status tables will be set 
accordingly, and these changes will be propagated to regis- 
tered clients via callback. The polling queue for the network 
element is made idle until a subsequent audit or any trap 
indicates that the agent is back online. 

[0332] Trap Receipt and Delivery 

[0333] The SNMP Mediator will receive traps from SNMP 
agents. The outline of this mechanism is as follows: 

[0334] At initialization, open a trap session with the 
HPOV SNMP infrastructure 

[0335] For each trap, translate the SNMP trap PDU into 
an EMAPI 55 event header 
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[0336] Deliver each EMAPI 55 event lo the Event 
Screener for filtering and delivery to registered clients. 

[0337] MIB-to-IDL Mapping 

[0338] A means will be provided to automate the mainte- 
nance of MIB changes and the corresponding EMAPI 55 
managed-object notation. An engine that includes an ASNI 
MIB parser will be used lo generate IDL and other files that 
depend on the MIB. The goal will be to minimize the amoimt 
of hand-crafted and maintained IDL. 

[0339] MIB Conventions 

[0340] MIB conventions will be defined and documented 
in coordination with the development of the AP agent. 

[0341] Service Object Description and Infrastructure 

[0342] A service object exists for each class of network 
element, maintenance unit or logical object within the sys- 
tem. As shown in FIG. 4, these are labeled SnmpNEMO and 
SnmpMO Class Objects. Each service object instance pro- 
vides services for client application access, and maintains a 
view of the attributes (as needed) for all instances of 
managed objects in that class. Example service objects 
include the AP, RCS and DSl. Examples of logical service 
objects include System and APSummary. FIG. 8 shows 
managed object classes and their containment relationships 
that may be used to manage the AP. FIG. 8 also shows some 
example Service Objects that may be added in the near 
future to manage other telecommunication network ele- 
ments. The OA&M shown can host the element manage- 
ment system. 

[0343] To maintain attribute values and provide client 
notifications for attribute changes, each service object main- 
tains a status table dynamically sized according to current 
configuration data and client polling needs. Information in 
this table will be identified through a class dictionary 
containing attribute codes and type information, available 
via common interface definition to both server and client 
code. For example, the AP object may contain attributes for 
maintenance state. Client applications will gain access to 
that state information for a specific AP via class methods 
which accept instance identifiers and attribute codes. The 
service object provides a centralized place where network 
element status is recorded. Instead of each application 
polling for attributes it needs, the service object manages a 
list of the registered clients and the attributes they are 
registered for. The combined set is then polled for by the 
SNMP Mediator. Additional class methods will be provided 
for performing operations specific to the unit type, such as 
remove, restore and diagnose. The specific protocol used for 
communication with the network element is specified by the 
service object. The SNMP protocol is used for communica- 
tion between service objects associated with the AP and the 
AP network element. Other managed object classes could be 
added that utilize a different protocol and encapsulate that 
knowledge in the managed object class. FIG. 9 depicts an 
AP service object and the data it contains. It also shows an 
example ECP managed object that could use a protocol other 
than SNMP for communication, 

[0344] Client Notification and Request/Resonse 

[0345] Each service object will provide methods for client 
access to attributes of its managed object instances. In 
addition to requesting the current value of attributes, clients 



can register for notifications of any changes to attribute 
values. Client access to attributes and registration for 
attribute notification is specified in terms of the following, 

[0346] A set of attributes for a specific instance of a 
managed object 

[0347] A client callback function for delivery of initial 
attribute values and subsequent changes 

[0348] All attribute values are delivered to the client by 
the client supplied callback object reference. A sequence of 
attribute code and value pairs are sent as an argument to the 
callback object reference. For the initial notification, the 
sequence contains the values of all requested attributes. For 
subsequent notifications of attribute changes, the sequence 
contains only those attributes that have changed, 

[0349] Client Command Request/Resonse 

[0350] Each service object for a class of network elements 
or maintenance units provides member functions to imple- 
ment requests for operations on specific instances of the 
class of network element or maintenance unit. For example, 
to remove a DSl unit from service in the AP, the remove 
method of the DSl service class is invoked. As with any 
other client requests, the client must have created a session 
prior to performing this operation. The specific instance of 
the maintenance unit and any command specific parameters 
must be specified. The operation will return a command 
sequence identifier (commandSeq) that is unique to the 
client session. The command sequence identifier is present 
in the header for all subsequent events (Acknowledgment 
and Command responses) for the command. 

[0351] Once the operation is validated at the server, a filter 
is registered for the client with the Event Distributor for all 
events that match the client's session and the command 
sequence identifier associated with the command. After 
successfully registering the event filter, a command request 
is sent to the SNMP Mediator where the instance is con- 
verted to the appropriate IP addresses and MIB command 
block values and generates the appropriate SNMP Set 
request. Command acknowledgments and command 
responses are transmitted from the SNMP agent by means of 
SNMP Traps. At the server, they are converted to Events and 
routed to clients with matching event filters. Note that there 
is a retry mechanism for SET requests where the element 
management system does not receive an associated SETRSP 
(detailed in the SNMP Mediator section) but no retry is 
attempted when a command fails (such as in the case where 
a failover was in progress). 

[0352] System initialed commands and responses will be 
routed similarly, using unique system session identifiers and 
callback functions. An example of this type of command 
would include a request to output the system status (OP) 
where a logical service object is responsible for servicing the 
request and generating the responses. These commands are 
processed within the element management system server 
and not by a network element through the SNMP interface. 
The element management system server must generate the 
command acknowledgment and command response events 
itself since it is responding to the command internally. 

[0353] The network element agent is responsible for pro- 
viding an acknowledgment trap indicating if the command 
request was accepted. Results of the command are then 
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delivered from the network element agent by a series of 1 or 
more command response traps. The last command response 
trap contains a last response or final report indication which 
is to be used within the server to detect the end of the 
command and to release server resources associated with the 
command (e.g. event filters). Since the command responses 
could be lost, a low level audit of command activity must be 
performed between the manager and the network element 
agent. The audit does not require that the agent keep 
command response information. The audit only checks to 
see if the command is still running at the agent. If a 
command response or trap is lost there is no recovery to 
regenerate the lost response. For cases where the network 
element cannot generate a command acknowledgment, or 
the acknowledgment is not received at the element manage- 
ment system server, the element management system server 
is responsible for generating an appropriate acknowledg- 
ment back to the client. The following summarize cases 
where the clement management system Server is responsible 
for generating the acknowledgment event back to the client: 

[0354] 1. Can^ transmit command block SET PDU to 
agent 

[0355] 2. No SETRSP received from the agent (after 
repeated retry of SET request) 

[0356] 3. SETRSP from agent indicates an error (such 
as an invalid object identifier) 

[0357] In all other cases where the agent receives the SET 
request and is able to "understand" its contents the agent is 
then responsible for generating the acknowledgment (either 
positive or negative). 

[0358] Object Attributes 

[0359] The following types of attributes can be associated 
with each managed object. For each category of attribute, 
the source of the attribute data differs (e.g. network element 
trap, network element polling, element management system 
local data). It is not required that all managed objects 
support all categories of attributes, instead the presence of 
the atu-ibutes is based on the needs of the managed object 
(for example, some managed objects have no state attribute, 
but have an alarm attribute. 

[0360] Persistent Attributes 

[0361] State and alarm attributes for managed objects are 
always maintained even if no clients are registered for the 
attribute. These attributes are updated by trap notification 
from the network element (and are audited by a low level 
periodic audit poll controlled by the Snmp Mediator). Main- 
tenance state is delivered by state change notifications, and 
alarm level attributes are delivered by alarm set/clear noti- 
fications. 

[0362] Configuration Attributes 

[0363] These attributes constitute configuration related 
information. These attributes are updated as a result of an 
event notification of configuration change on the managed 
object. When a configuration event notification is received 
noting either an insert or update of configuration, the man- 
aged object performs a single request to get the current 
values of all attributes for the specified (this is also known 
in SNMP as trap directed poUing). When the configuration 
event indicates a configuration delete, the managed object 



performs the associated deletion of the instance. As with 
Persistent attributes, config attributes are audited by a low 
level periodic poll controlled by the Snmp Mediator (in fact 
it is the same audit). An example of this type of attribute is 
apLogicalld. Note that some attributes marked as Config 
only change when the SNMP agent reboots. Therefore, the 
network element will never issue any config change notifi- 
cations on these attributes. Hiey are categorized as config 
because the managed object requests their values along with 
other config attributes when the config notification is 
received for a new instance of the managed object. 

[0364] Audit Attributes 

[0365] The value of these attributes are only maintained 
through a periodic low level audit. Examples of this type of 
attribute are the active conunand table command session and 
command sequence number. 

[0366] Polled Attributes 

[0367] The current value of these attributes are only 
maintained if a cUent is registered for notifications of 
changes to the attribute. These attributes are polled for at a 
15 second polling rate by the SNMP Mediator. An example 
is the AP sysUpTime attribute. 

[0368] Internal Attributes 

[0369] These attributes are based on intemal data or 
derived from other attributes. An example is the isolated 
attribute in the AP network element. Its value is based on an 
isolation indication detected by the SNMP Mediator when 
communication is lost to a network element (or subsequently 
restored). For SNMP based managed objects, all attributes 
that are not internal, directly represent an associated MIB 
attribute. 

[0370] Service Object Base Class Functionality 

[0371] Much of the basic behavior of each object is 
present by means of inheriting base classes that contain the 
specific manager functionality. For example, client registra- 
tion and polling will be defined in base classes shared across 
all service objects. The following sections describe these 
common behaviors available to all service object classes. 

[0372] Managed Object Base Class 

[0373] This class pro4vides definitions of the basic inter- 
faces that all managed objects must support. This includes 
providing client interfaces for things such as managed object 
configuration notification and attribute update notification. 
Specific service objects would all inherit this base class. 

[0374] NE Managed Object Base Qass 

[0375] This class (derived from managed object base 
class), provides network element specific functionality on 
top of the basic managed object class. This includes pro- 
viding client interfaces for network element configuration 
notification. It is responsible for handling network clement 
related equipage notifications from configuration data ser- 
vices (AP equipage changes) and notifying the SNMP 
Mediator of these changes. The SNMP Mediator must be 
notified of these changes in order to provide appropriate 
routing and translation between the Managed Objects and 
the network element. Specific network element service 
objects would all inherit this base class. 
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[0376] CUem Notification Registration 

[0377] Each service object must manage a list of clients 
and the attributes for which they are registered. This list 
must contain a session handle, the list of attribute codes, and 
the instance identifier(s) for specific managed object 
instances. This functionality must also provide methods to 
efiGciently search this list based on attribute code and 
instance identifier so that registered clients can be notified of 
changes. Client registration must be coordinated with the 
Client Session Manager to provide for graceful cleanup 
when abnormal client termination is detected. 

[0378] The Client Registration Functionality: 

[0379] Provides interface to clients for attribute regis- 
tration given the following parameters 

[0380] client session id 

[0381] managed object instance identifier (specific 
id, range, or all in class) 

[0382] set of attribute codes 

[0383] callback function for delivery of changes 

[0384] Provides general container and data stnicmres 
for managing a list of client registrations 

[0385] Provides methods for construction and delivery 
of client callback with attribute code/values. 

[0386] Provides interface with client for de-registration 

[0387] Provides interface with Client Session Manager 
for de -registration when abnormal client termination is 
detected via audit. 

[0388] Polled Attribute Management 

[0389] Attribute polling is needed for element manage- 
ment system initialization (e.g., upon element management 
system initialization, the only way to obtain status is through 
polling), attribute values that are not trap -directed, and 
audits (i.e., UDP is an unreliable transport and as such, traps 
may be lost). Trap -directed attributes are stored on the 
element management system in memory for use by multiple 
clients. There may also exist other attributes whose value is 
only obtained through polling, and that polling will only be 
initiated when a client has informed the object that it is 
interested in notifications of state changes to those variables. 
In that case, the object must request that the SNMP Mediator 
poll network element at regular intervals (15 seconds) to 
determine if any of the variables of interest have changed. If 
a change is detected, registered clients must be notified by 
means of a client callback. These polled attributes arc also 
stored in memory. The manager of these attributes are as 
follows: 

[0390] Maintains the attribute table (allocation of 
attribute table, instance identifier management, changes 
to the attribute table based on configuration changes) 

[0391] Informs the SNMP Mediator of the current set of 
attributes that are to be polled. When a client registers 
(or de-registers) the set of attributes that must be polled 
for may change. If it does, the SNMP Mediator mtist be 
informed. 

[0392] Handles poll responses from the SNMP Media- 
tor. When a set of polled data is delivered (via server 



callback function) attribute values must be compared 
with the current values in the attribute table. When the 
value has changed, the value in the attribute table is 
updated and clients must be notified of the change. 
Note that if more than one attribute has changed for a 
managed object instance, the changes will be grouped 
and delivered to each registered client on a managed 
object instance basis. 

[0393] Trap Directed Attrebute Polling Management 

[0394] For network elements utilizing SNMP, all alarm, 
configuration changes and basic state changes (including 
non alarmed maintenance states) are delivered to the man- 
ager from the Agent through the use of an enterprise specific 
SNMP trap. These traps are received by the SNMP Mediator 
where they are translated into EMAPl 55 Events and passed 
along to the Event Distributor. They are then delivered to al! 
clients that have registered a filter matching the data in the 
associated Event. The Summary Alarm/Status functionality 
of each class of objects registers a filter with the Event 
Distributor to request delivery of all alarm and state change 
events for all instances of objects within its class. When a 
alarm or state change event is received by the Summary 
Alarm/Status Manager, the attributes for the appropriate 
instance are updated, the summary attributes for the class are 
updated, and all clients registered with the object for state 
change notification on the affected attributes are notified via 
their client callback functions. 

[0395] Registers appropriate filter with Event Distribu- 
tor for all events on instances of this managed object 
class (alarms, state changes, configuration notifica- 
tions). 

[0396] Handles events from the Event Distributor. 
When a trap is received, attribute values in the Event 
are compared with the current values in the attribute 
table. When the value has changed, the value in the 
attribute table is updated and clients must be notified of 
the change. 

[0397] Interfaces with SNMP Mediator to perform low 
frequency (audit) poll of attributes in the managed 
object class associated with traps. 

[0398] Handles low frequency audit poll responses 
fi-om SNMP Mediator. 

[0399] Client Interface Components 

[0400] The following sections describe the components 
present on a client of the element management system server 
to provide the client interface to NE management. Specific 
client interface style and content will be addressed after the 
architecture with input from human factors and element 
management system engineering. In addition to making the 
client interface as easy to use as possible, the client interface 
must retain similarities with the current maintenance model 
such that little retraining of the end chenl (technician) is 
necessary. Sample Web pages can be found in the attach- 
ments to this document. 

[0401] AP or Network Element Telnet Access 

[0402] Direct cut -through access to the AP is required to 
perform system administration and some configuration func- 
tions, and as a means to access the AP command line 
interpreter if the element management system is not opera- 
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tional. To provide this access, the client platform must 
support a telnet application and a suitable terminal emula- 
tion to run a visual editor such as vi. On an X terminal, an 
xterm terminal emulator and use of the telnet application 
will be sufficient. On the Microsoft Windows platform, use 
of an X terminal emulator will provide the same access as an 
X terminal, or the Windows telnet application on a PC may 
be used. 

[0403] WebBrowser 

[0404] The primary client interface is provided by an 
HTML web browser. Both Netscape navigator and 
Microsoft Internet Explorer are to be supported. The web 
browser must support the execution of Java 1.1 applets and 
at least HTML version 3.2. The following client terminal 
configurations must be supported: 

[0405] X Terminal with Netscape browser running on 
the element management system. 

[0406] Sun workstation with Netscape browser running 
on workstation. 

[0407] PC (Windows 95 or NT 4.0) with either 
Netscape or Microsoft IE running on PC. WEB PAGES 

[0408] To provide web based network management access 
for the AP, web pages providing the following functionality 
must be developed. FIGS. 10, 11, 12 and 13 show sample 
page layouts): 

[0409] 1. Top level page: Initial entry to system. Pre- 
sents a menu of options and potentially high level 
system status. 

[0410] 2. Network page: Hosts AP system level sum- 
mary application 

[0411] 3 . AP page Hosts AP detailed NE status page for 
a single AP. A version of the page is constructed "on the 
fly" based on the AP logical number in the URL. The 
AP logical number and any other parameters are passed 
to the AP detailed NE status applet. 

[0412] 4. Alarms page: Hosts the Alarm list applet. 

[0413] Note that page layout and navigation is determined 
by working with human engineering factors. 

[0414] Client must be able to: 

[0415] 1. Access each page directly. Secure access 
(through web ID validation) must be provided for the 
initial access to these pages, but not for requests for 
subsequent pages as long as the same browser session 
is used. 

[0416] Java-based GUI Infrastructure 

[0417] This section describes base components that arc 
necessary for implementing the AP specific GUI applets. A 
number of these components (especially the GUI compo- 
nents) may be satisfied (or based upon) commercial 3*^** party 
products (for example Rogue Wave JWidgets, or Microline's 
Grid widget). Also, 3"^** party non GUI container and algo- 
rithm classes (either Rogue Wave or JGL for example) 
should be considered to enhance the set that comes with the 
Java Development Kit. 

[0418] The following sections describe applications that 
use this architecture. 



[0419] AP Simimary Application 

[0420] This application provides summary information for 
all AP processors in the system. The summary information 
consists of the highest alarm level, administrative state and 
equipage status of all AP processors. Any changes to the 
configuration of displayed summary information are 
updated on the display within 30 seconds of the change. 
State changes are to be displayed within 15 seconds of the 
state change in the AP. In addition to presenting summary 
and equipage information, the appUcation supports naviga- 
tion to detailed status pages for each of the AP processors. 
It also provides a pop up menu (and any necessary dialog 
boxes) for execution of AP commands (e.g. RMV AP). A 
command response area or dialog box is also provided for 
display of command responses. 

[0421] This application initiates a session with the element 
management system server (through the Client Session 
object) and registers with the network element service 
objects (the AP object) for the configuration information and 
attributes that it needs to provide a display of the AP network 
element summary (e.g. highest alarm level and status sum- 
mary). An initial set of attribute values is delivered to the 
client and any subsequent changes to those attributes are 
delivered (from the summary alarm/status manager in the 
service object). Note that only the changed attributes are 
delivered in the subsequent callbacks unless the client 
requests a "reload" of attributes, 

[0422] A sample Network Web page can be found in the 
attachments. 

[0423] Network Element (NE) Detailed Status Application 

[0424] This application presents a detailed view of the 
status of maintenance units within an AP network element. 
Any changes to the configuration of displayed summary 
information are updated on the display within 30 seconds of 
the change. State changes are to be displayed within 15 
seconds of the state change in the AP. This application 
initiates a session with the object server (through the System 
object) and registers with the AP service objects (specific 
network element instance and maintenance units) for 
attributes that it needs to provide a display of the AP element 
status. An initial set of attribute values is delivered to the 
client and any subsequent changes to those attributes are 
delivered (from the attribute manager in the service object). 
Note that only the changed attributes are delivered in the 
subsequent callbacks unless the client requests a "reload" of 
attributes. The detailed status application may also provide 
context sensitive command execution through the use of pull 
down (or pop up) menus. The interface for command 
execution and display of command results is the same as the 
interface described in the "Command Handler** section 
above. 

[0425] A sample AP Web page can be found in the 
attachments. 

[0426] Alarm List (Active Alarm Browser) Application 

[0427] This application provides an alarm browser inter- 
face to active alarms within the system. The client can 
specify a filter to hmit the set of alarms (e.g. by network 
element, alarm level etc). The application registers it's filter 
and a callback function with the active alarm manager 
through the EMAPI 55. An initial set of active alarms 
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matching the filler criteria is delivered lo the client aloag 
with subsequent updates to set or clear alarms. Upon grace- 
ful termination the client disconnects from the active alarm 
manager (or an internal audit in the active alarm manager 
detects this and cleans up). 

[0428] A sample Alarms Web page can be found in the 
attachments. 

[0429] Locale Text Fonnatting Services 

[0430] This service provides the infrastructure for mul- 
tiple human language support. This service is used by any 
application that interacts with an end client through display 
of text: this includes the ROP formatting process, the web- 
based client applications, and any local logging on the 
element management system. 

[0431] The following functionality will be provided: 

[0432] Access to a database of text formatting strings 
used by clients for formatting 

[0433] Lookups are based on an integral key and a 
corresponding ASCII string is returned 

[0434] The database contains key and ASCII values and 
will reside on disk. The storage format and caching 
mechanisms will be designed so minimize lookup 
speed. 

[0435] Both local and remote clients can be served. 

[0436] Adherence to X/Open CAE (XPG4) source mes- 
sage file format. 

[0437] Conamands and Reports 

[0438] Each managed object class will adhere to the 
interface specified by the managed object base class (pro- 
vide for client attribute registration, notification, configura- 
tion registration and notification), and will manage equi- 
page, alarm and status for all instances of managed objects 
in that class. Each class will also provide methods to 
implement managed object specific commands. These meth- 
ods will incorporate appropriate argument validation (e.g. 
range checks, target network element is equipped before the 
command is executed. 

[0439] Besides the A? generated reports, the element 
management system will generate reports for the following 
conditions: communication is lost with an AP, communica- 
tion is established with an AP (cold start trap), and all APs 
are out of service. 

[0440] Overload Control 

[0441] Overload control in the element management sys- 
tem server is accounted for primarily in the design (as 
opposed to here in this document). Specifically, status 
requests (polling, auditing and one-time GET requests) are 
limited by the number of simultaneous HPOV sessions 
supported by the element management system and the size 
of the tunable sliding window managed for each AP. Further, 
the event stream is limited by the throttling mechanism 
implemented by each SNMP agent. On the client side, the 
element management system will support a limited number 
of active client sessions, each of which may run a limited 
number of applications. The bottom line is there won't be 



enough network or client generated trafiSc to warrant the 
development of additional overload controls for the first 
phase. 

[0442] Additional development should extend overload 
controls to safeguard against an uncontrolled event stream, 
and monitor and restrict the number and scope of client 
requests associated with each application. 

[0443] The following areas of concern have been identi- 
fied and will be used as the starting point to examining 
overload control: 

[0444] aient Overload: 

[0445] Registering for too high a volume of data 

[0446] Creating too many sessions: note that 
adequate resources are currently allocated for inter- 
nal server sessions 

[0447] igh-frequency callbacks (traps for example) 

[0448] Server Overload: 

[0449] Too high a volume of polling from SNMP 
Mediator to NE agents 

[0450] Trap floods: too many traps received over 
short period from NE agents 

[0451] Softwre Version Management 

[0452] The plan of record for overall AP/element man- 
agement system/ECP software version management is as 
follows: 

[0453] For software retrofit for other applications, the 
element management system Server and the AP are 
retrofited to the same new version of element man- 
agement system software. 

[0454] Al element management system Software 
Update: 

[0455] The element management system Server is 
updated first 

[0456] The APs are updated one at a lime 

[0457] The element management system Clients 
will detect the element management system 
Server is down, and will need to reinitialize when 
the element management system Server is back 
online. 

[0458] For element management system SUs, the element 
management system software on the element management 
system server must be compatible with the old version and 
new version of software on the AP. To support this compat- 
ibility, the element management system server is required to 
support MIB versions j and j+1 simultaneously. Element 
management system version management extends to ele- 
ment management system client applications as well, which 
must have knowledge of the MIB version on a given AP and 
be able to act accordingly. 

[0459] During a software retrofit application and clement 
management system Server SU, the element management 
system Clients will go down and will need to re -initialize 
once the element management system server is back up. The 
definitive requirements for element management system 
GUI Client version management will be described in the 
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element management system GUI Client Capability 
Require ments/High-Level Design document The design of 
the MI B is that it contains a very detailed description of the 
element management systcm/AP interface. Tlie MIB is 
intended to serve as much as possible as a single element 
management system/AP interface definition. As such, its 
details may need to be modified more frequently than at each 
Generic Retrofit. The SU approach will not guarantee that an 
element management system Server running a different MIB 
version than a corresponding AP SNMP Agent will be able 
to conduct error-free operations, but rather will enumerate 
the possible ways a MIB could change firom one release to 
another and will specify the way version mismatches in each 
case will be handled and the kind of error handling that will 
be needed. The overriding goal is to maximize a technician's 
ability to perform the method in accordance with the inven- 
tion on any available AP even if that AP is not running the 
same MIB version as the element management system 
server. 

[0460] Security 

[0461] This functionality provides a method of client 
based access control of network elements, maintenance units 
and operations on network elements/maintenance units. 
Upon startup, a client application must register with the 
server by providing identification of the client host, port, 
client, and a password. The server retrieves the client record 
from local data services and returns a session object to the 
client noting the client's access permissions. This informa- 
tion may be used to provide some level of access control in 
the client application (e.g. deactivating menu element man- 
agement system for maintenance operations that are not 
allowed). In any case, all client requests are validated at the 
server. Each managed object class requires the session 
identifier as a parameter to each public method. The access 
permissions associated with the session are examined before 
authorizing client execution (e.g. remove operation). Note 
that there is a predefined "system session" with global 
access permissions for use by infrastructure components 
which make use of the same interface definition. 

[0462] The version of SNMP that will be used by this 
architecture is SNMP V2c. This version of SNMP provides 
no further security enhancements over the community name 
based security in SNMP VI. It provides no mechanism to 
authenticate the source of a management message, or to 
prevent eavesdropping on the messages on the network. 
Because of this, it is strongly recommended that the network 
that is utilized for the element management system to AP 
SNMP traffic be a closed network and not part of the service 
providers public LAN or intranet . 

[0463] The command line interpreter application (which 
resides only on the element management system server) is 
applicable to any client with a login on the element man- 
agement system server. Thus, the client based access control 
described above provides a means to restrict access on a 
command/client basis. 

[0464] Major Sub-components of the AP 

[0465] A functional block diagram of the AP is shown in 
FIG. 14. 

[0466] SNMP Agent: Provides the interface to the ele- 
ment management system Server using the SNMP 
protocol and a MIB defined specifically for the AP. 



Sends AP events and command acks/responses to the 
element management system Server as SNMP TRAPs; 
responds to requests for managed object data (SNMP 
GETs); passes command requests (SNMP SETs) to the 
Command Handler. 

[0467] AP MIB: An SNMP MIB defined specifically for 
the AP. Contains the definition of all AP objects to be 
managed from the element management system Server, 
as well as the definition of all AP TRAPs to be sent to 
the element management system Server. 

[0468] Agent Configuration File; contains values need 
by the Agent to communicate with the Manager, which 
resides on the element management system Server. 

[0469] Event Handler: responsible for both the filtering 
and forwarding of events to the SNMP Agent. In 
response to events that are generated, updates the 
Network Element Status Table with data that is to be 
"remembered" by the AP (so that the element manage- 
ment system Server may query or poll for it later). 

[0470] Event API: AP applications use this API to 
generate an event (state change, alarm, informational 
message, configuration). The event is passed to the 
Event Handler, 

[0471] Network Element Status Table (NEST): a reposi- 
tory for aU status that the element management system 
Server may query for. Current status, including state 
variables and list of outstanding alarms, for each Man- 
aged Object will be maintained here. In addition, the 
Hst of outstanding commands wiU be maintained here. 

[0472] NE Status API: an interface for writing to and 
reading from the Network Element Status Table. 

[0473] Event Cbnfiguration File (ECF): text file, (pos- 
sibly editable by the technician), which defines which 
events are to be logged locally on the AP and/or passed 
to the SNMP Agent for transmission to the element 
management system Server. As per requirements, there 
will be a set of events that will always be logged and 
forwarded to the clement management system Server — 
the technician will not be able to modify these. There 
may be other events defined (as the development phase 
proceeds) which may be edited by the technician. The 
ECF also defines X.733 values (e.g. severity) associ- 
ated with alarms and informational messages. 

[0474] Admin Log: file containing a customer-viewable 
log of events generated on the AP; which events are 
logged is controlled by the ECF. 

[0475] The following sub-components are considered part 
of the AP infira-structure software. 

[0476] Command Handler: manages all commands that 
are to be executed on the AP. Interfaces to a command 
source (also known as a Command Handler Access 
Point, or CHAP), such as the SNMP Agent, the AP Text 
Client, or the ECP Agent via the Command/Response 
API. Responsible for triggering and monitoring the 
command to be executed via the RAP API. Generates 
the command acknowledgment. Routes the command 
acknowledgment and command responses back to the 
command source. Maintains list of active commands in 
the NE Status Table. 
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[0477] Command/Response API: interface between a 
cooiniand source and the Command Handler for the 
purpose of issuing commands and obtaining command 
acknowledgments and responses. 

[0478] RAP API: a general API for spawning a process 
and obtaining the results of the process execution. 
Generally, RAPs will be used to carry out a mainte- 
nance command on an AP resource. RAPs may spawn 
other processes, if necessary, 

[0479] Text Command Interpreter: text-based command 
client for generating commands and receiving 
responses locally on the AP. Intended to be used when 
the element management system Server is unavailable. 

[0480] IDS-AP: maintains the data tables of the IDS on 
the AP; receives triggers, representing changes in data, 
from the IDS on the ECR 

[0481] IDS (Configuration) Data: a repository for AP 
configuration data obtained from the ECP via IDS-AP. 

[0482] IDS API: an API for obtaining configuration data 
provided by IDS-AP. 

[0483] ECP Agent: interface to Status Display on the 
ECP; interface to IDS-AP for processing triggers indi- 
cating change in data. Passes triggers on to interested 
application processes. 

[0484] Audit Controller: audits status and alarms 
among RCC, NEST, and resource managers (e.g. 
CCM). 

[0485] AP State Monitor: detects and reports RCC- 
related state changes and alarms. This includes state 
changes and alarms reported by Resource Monitors 
RCC process monitoring software. 

[0486] SNMP Agent 

[0487] The element management system interfaces to the 
AP via the SNMP Agent. A MIB is used to define the 
interface between the element management system Server 
and the Agent and is common to both the element manage- 
ment system Server and the Agent. The Agent is described 
here and the MIB is described in the following section. The 
Agent communicates with the element management system 
Server using the Internet standard Simple Network Man- 
agement Protocol (SNMP) (see Internet document RFC- 
1157) via a standard UDP/IP port. In this architecture, the 
intent is to use SNMEV2c, which provides enhanced capa- 
bilities over SNMPvl, such as the GETBULK operation. 

[0488] SNMP provides three basic management functions: 

[0489] GET (also GETNEXT and GETBULK): obtains 
data from a managed system (retrieves attributes asso- 
ciated with a managed object, as defined in the MIB). 
The managed system must respond to a GET with a 
GET-RESPONSE. 

[0490] SET: usually used to make modifications to the 
managed system. The managed system must respond to 
a SET with a SET-RESPONSE. In this architecture, 
SETs are used to trigger commands to be executed on 
the AP. 

[0491] TRAP: a way for the managed system to send 
asynchronous notifications to the Manager. 



[0492] SNMP Agent Functionality 

[0493] The SNMP Agent will perform the following basic 
functions: 

[0494] I. Receive SNMP packets sent by the SNMP 
Manager at the clement management system Server and 
process each one as follows: 

[0495] A. GET/GET-NEXT/GETBULK packet: 
Obtain the current values of the managed object 
attributes requested in the packet by accessing either 
the Network Element Status Table or the Configu- 
ration (IDS) Data, as appropriate. The requested 
attributes and their values are stored in a GET- 
RESPONSE packet and returned to the Manager. 

[0496] B. SET packet: Map an SNMP SET request 
into a command request message, as defined by the 
common Command/Response API. The command 
attributes, as specified in the SNMP packet and 
defined in the MIB, will be mapped in to correspond- 
ing message elements. The message will be passed to 
the Command Handler via the Command/Response 
API. 

[0497] The Agent will send a SET-RESPONSE back 
to the Manager. If the SET request was invalid such 
that the Command handler could not determine a 
command to nm, or if the command could not be 
passed to the Command Handler, the SET-RE- 
SPONSE will indicate an error. The Manager must 
interpret a SET RESPONSE error and generate a 
command acknowledgment indicating an error 
occurred. 

[0498] The Agent must allow for the case where the 
Manager may send an identical SET request. This 
can occur if the Manager does not receive the 
SETRESPONSE (lost). The Agent will remember 
the last SET request processed for a given client 
session (the client session info is defined in the MIB 
as common attributes for all commands) and will 
only pass the command to the Command Handler if 
the request is new. If the request is old, the Agent will 
simply send another SET-RESPONSE to the Man- 
ager. 

[0499] n. Receive messages from the Command Han- 
dler and process each one as follows: 

[0500] A. If the message is a Command Acknowl- 
edgment, map it into a Command Acknowledgment 
TRAP packet. The MIB will define a Command 
Acknowledgment TRAP that will be used for all 
commands. A command acknowledgment will take 
the form of a simple value to indicate the status of the 
command, such as the command was rejected, timed- 
out, is complete, or is in progress with command 
responses to follow. 

[0501] B. If the message is a Command Response, 
map it into a Command Response TRAP packet. The 
MIB will define a common Command Response 
TRAP block that will be passed back in all command 
responses. In addition to the common Command 
Response TRAP block, there will be specific defini- 
tions in the MIB for each type of command response 
than can be generated. Note that there is no provision 
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made to save Command Responses in case ihey are 
lost (perhaps the command response handling at the 
element management system Server can report on 
lost responses). Nor, is there any provision to guar- 
antee that responses are returned in the correct order. 

[0502] III. Receive messages from the Event Handler 
and process each one as follows: 

[0503] A. Map the particular event into a correspond- 
ing TRAP packet. There are four possible types of 
events that can be received by the Agent and each 
event type will be mapped to a specific TRAP, as 
defined in the AP MIB. 

[0504] 1. State Change: indicates a change in value 
of one or more of the variables associated with a 
managed object. Managed object states will be 
maintained in the NE Status Table and the Man- 
ager may query the Agent for any or all stales 
associated with the managed object. The Agent 
will map the variables and new state values in the 
event message into their corresponding MIB 
object identifiers and values in a TRAP packet, 
and send the packet to the Manager 

[0505] 2. Alarm: indicates a condition of an unex- 
pected nature which requires special and persis- 
tent technician notification. May also be used to 
indicate a clearing of such a condition. Each alanm 
is associated with a managed object and has a 
definition specific to that managed object in the 
MIB. There is an alarm block defined in the MIB 
that is common to all alarms. Alarms, like man- 
aged object states, will be maintained in the NE 
Status Table, and the Manager may query for 
active alarms. The Agent will map the alarmed 
event into the common MIB alarm block plus the 
specific attributes defined for the managed object. 

[0506] 3. Informational message: is similar in sub- 
stance to an alarm, but is a condition that does not 
require the persistence of an alarm. The intent of 
an informational message is a condition which 
requires logging (say at the element management 
system Server and/or on the ROP) but is either not 
considered important enough to be maintained as 
an alarm (i.e. persistent view to the technician), or 
is a condition which can not be automatically 
retired when the condition disappears. An alarm 
defines a condition which must be able to be 
retired, either automatically or as a result of some 
technician action. The Agent will map the Infor- 
mational message event into the common MIB 
Informational message block plus the specific 
attributes defined for the managed object and send 
it to the Manager. 

[0507] 4. Configuration Change: indicates that the 
configuration data for a given managed object has 
changed in some way (i.e., the managed object 
was created or deleted, or the configuration data 
associated with the managed object was updated). 
The Agent will map the Configuration Change 
event into the common MIB Configuration 
Change block and send it to the Manager. The 
Manager is then responsible for querying the AP to 
obtain the new/updated configuration data. 



[0508] IV. The Agent wiU throttle TRAPS going to the 
clement management system Server so as not to over- 
whelm the Manager. Throttling will be based on a fixed 
maximum rate coming from the AP. The throttling 
performed by the Agent will be priority-based, such 
that command acks and responses would take prece- 
dence over configuration changes, which would take 
precedence over alarms, which would take precedence 
over informational messages. The details of TRAP 
throttling will be specified during the design phase. 

[0509] SNMP Agent Initiahzation 

[0510] In order to communicate with the SNMP Manager 
on the element management system Server, the Agent 
requires certain information: 

[OSU] 1. The IP address of the SNMP Manager is 
required in order to send SNMP TRAPs; a standard 
hostname will be assumed to exist in the /etc/hosts file 
on the AP and the Agent will obtain the IP address of 
this host on startup. Default IP addresses will be setup 
at staging of the AP. 

[0512] 2. The SNMP read and write community strings. 
Community strings are a form of SNMP security: the 
strings that the Manager will send must match what the 
Agent is expecting in order for the Agent to allow a 
GET(read)/SET (Write). These strings will be obtained 
from a command-line option when the Agent is started. 
Commandline parameters are specified in the RCC 
configuration file. 

[0513] The SNMP Agent will exist as part of the Element 
Management Infrastmcture Platforrn Virtual Machine 
(PVM) on the AP , and as such will be started by the Reliable 
Cluster Computing infrastructure. 

[0514] Upon startup, the SNMP Agent will perform the 
steps necessary to gain access to the NE Status Table and 
Configuration Data; determine the Manager's IP address (as 
stated above); and will send a standard SNMP Cold Start 
TRAP to the Manager. 

[0515] The Agent will respond to SNMP GETs on the 
standard Interact "system" group objects. This is required by 
the HP Open View package that is being used on the element 
management system Server. 

[0516] APMIB 

[0517] The AP MIB is the data definition shared between 
the SNMP Manager on the element management system 
Server and the SNMP Agent on the AP. It contains the 
definition of: 

[0518] Common attribute blocks ("headers"), such as 
those defined for commands, command acknowledg- 
ments, alarms, etc. (see "MIB Conventions" below). 

[0519] All state variables, commands, command 
responses, alarms, and informational messages associ- 
ated with the objects that are to be managed from the 
element management system Server. The managed 
objects are intended to include the AP itself, RCS 
virtual machines, the ethemet, etc. 

[0520] Objects required for auditing, such as the list of 
active commands (so that the element management 
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system Server may audit its view of outstanding com- 
mands \yith the AP's view). 

[0521] MIB Conventions 

[0522] As mentioned previously, several conventions will 
be applied to the MIB to support this architecture. They are 
listed in the following sections "Binary" versus "ASCII" 
Attributes. 

[0523] The intent is that the attributes defined in the MIB 
will, in general, be defined as binary values, as opposed to 
ASCII strings. This allows the text-formatting of the 
attribute values (al the element management system Server) 
to use locale text formatting (so that the text appears in the 
appropriate human language). 

[0524] SNMP agents preferably support the above vari- 
able. It is used by the Manager to determine whether this is 
an MIB (supporting the other interface conventions 
described in this section), and also to provide a versioning 
mechanism to support MIB changes. Upon initialization, the 
Manager will attempt to perform a GET operation on this 
variable. If it does not exist, the Agent does not support the 
enhancements required by this architecture, 

[0525] Common Command Block 

[0526] To support command requests, the MIB must sup- 
port a specific set of variables to allow for all parameters for 
command execution to be specified in an atomic operation. 
This set of variables is called the command block. The 
command block provides a way to "register" a command 
request with an identifying tag that is used to route the final 
response (delivered by a TRAP) to the originating requester. 
The command block will contain such parameters as: 

[0527] A session ID that relates the command to a 
particular client session. 

[0528] A command sequence that makes the command 
unique within a particular client session. 

[0529] An object instance identifier (e.g. "7" for an 
"RCS" managed object) to identify the particular 
instance of the object that the command is to be 
performed on. 

[0530] A command operation (e.g. REMOVE). 

[0531] Additional parameters specific to the command are 
not part of the common command block. 

[0532] Common Command Acknowledgment and Com- 
mand Response Blocks 

[0533] In order to route Command Acknowledgments and 
Command Responses back to the originating client, the 
TRAPs that are generated to produce acks and responses 
must contain the common command block attributes (see 
above) from the initial command request. Command 
Responses must also contain a response sequence and a flag 
indicating last response. The common command block 
attributes will be passed to the Command Handler by the 
SNMP Agent and must be returned from the Command 
Handler to the Agent (i.e. this must be part of the Command/ 
Response API), so that the Agent can return them in a 
Command Response TRAP. 



[0534] Common Alarm and Informational Message 
Blocks 

[0535] Alarms and Informational messages will have a 
common attribute block defined. Attributes such as alarm 
level, alarm cause, alarm ID (a unique value per outstanding 
alarm) will be defined, 

[0536] Common Configuration Change Event Block 

[0537] There will be a common attribute block defined for 
all Configuration Event TRAPs. Attributes such as the 
managed object instance identifier and the configuration 
operation (insert, update, delete) will be defined. 

[0538] Unit Hierarchy Addressing within the MIB 

[0539] SNMP MIBs currently provide only one method to 
structure data: a simple twodimensional table with scalar- 
valued entries. This fimited way of structuring M variables 
does not directly support the more complex structure of a 
network element such as a cell site. A cell site has many 
units, each of which has a set of variables specific to that 
unit. The units are structured in a hierarchy. 

[0540] To reference a specific attribute (or a set of 
attributes) of a sub-unit lower in the hierarchy, a multi- 
column key consisting of an identifier for each unit in the 
hierarchy will be used (e.g. to reference a sub-unit like CCC 
2, ecu 1, the last two digits of the SNMP object identifier 
would be "2.1"). The SNMP GETNEXT operation supports 
a convention (which must be supported by the Agent) to 
request an attribute by specifying the multicolumn key as an 
object identifier. 

[0541] Note: Currently, there has been no such unit hier- 
archy deemed necessary for the AP managed objects. 

[0542] Event Generation and Processing 

[0543] Applications on the AP are responsible for gener- 
ating events to reflect: 

[0544] Current status and alarms associated with AP 
managed objects. 

[0545] Changes in configuration data associated with 
AP managed objects. 

[0546] Informational messages that may be of interest 
to Network Management applications. 

[0547] In order to prevent inconsistencies, it is assumed 
that one and only one application will be responsible for the 
status and alarms of a particular managed object instance, 
and thus, be responsible for maintaining an accurate view of 
the managed object at aU times by use of the Event API. 

[0548] The following sections describe the major compo- 
nents involved in event generation and processing. 

[0549] Event API 

[0550] The Event API provides a mechanism for applica- 
tions on the AP to generate events, and communicate these 
events to the Event Handler for possible recording, logging 
and/or forwarding to the element management system 
Server. The API includes: 

[0551] The definition of all possible events in the sys- 
tem. Each event will be classified into one of the four 
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possible types of events, as discussed earlier in this 
document: state change, alarm, informational message, 
or configuration change. 

[0552] Ameans to initialize the API. Internally, the API 
will use the UX inter-process communication library to 
send messages to the Event Handler. 

[0553] Ameans to pass the alarm text associated with a 
given alarm occurrence. The text will be encoded in a 
machine- and language-independent form for transmis- 
sion to the element management system. Hie means to 
encode text will be provided by a National Language 
Support (NLS) Ubrary. 

[0554] A means to clear all alarms previously generated 
by this application. This is intended to be used when an 
application re -initializes and must clear all outstanding 
alarms related to all managed objects for which it is 
responsible. This capability may or may not be needed 
in Generic 13. 

[0555] A means to clear all alarms associated with a 
particular managed object instance. This is intended to 
be used when a particular managed object is initialized 
or brought in to service. For example, there may be 
several outstanding alarms on a DSl object related to 
in-service operation. When the DSl goes out-of-ser- 
vice, the application managing the DSl may want to 
clear all outstanding alarms on that DSl. 

[0556] Event Handler 

[0557] The Event Handler will exist as part of the Platform 
Virtual Machine on the AP, and as such will be started by the 
Reliable Cluster Computing infrastructure. 

[0558] The major functions of the Event Handler are: 

[0559] I. Read the Event Configuration File to deter- 
mine which events are to be recorded (attribute changes 
and alarms), logged, and/or passed to the SNMP Agent 
for transmission to the element management system 
Server. The ECF also defines whether an event is an 
alarm or an informational message, and the X.733 
values associated with alarms and informational mes- 
sages. 

[0560] IL Monitor the ECF (e.g. UNIX stat system caU) 
on a regular basis to detect changes in the ECF. 

[0561] III. Receive messages from applications on the 
AP and process each one as follows: 

[0562] A. If the event is to be logged, do so. 

[0563] B. If the event is one which requires recording 
(an attribute change or an alarm), update the NE 
Status Table using the NE Status API. 

[0564] C. If the event is to be passed on to the 
element management system Server (by default, all 
events will be passed), send it to the SNMP Agent 
using the UX inter-process communication library. 

[0565] Network Element Status Table 

[0566] A repository for all non-configuration data that the 
element management system Server may query for. This 
includes: 

[0567] Current managed object status, on a per-man- 
aged-object-instance basis. 



[0568] List of outstanding alarms, on a per-managed- 
object-instance basis. 

[0569] Active Command Table, so that the SNMP 
Agent has access to the list of commands that are 
currently outstanding from the element management 
system Server, for audit purposes. 

[0570] Network Element Status API 

[0571] Provides a mechanism to read and write the Net- 
work Element Status Table. The API blocks readers while 
the table is being updated so that the data is kept consistent 
(^■g ) by using a semaphore). Supports "wildcard" clearing 
of alarms as described above in the "Event API" section. The 
intention is that the Event Handler will be the one and only 
one application that will use the write API, while other 
apphcations, such as the ECP Agent and the SNMP Agent, 
will use the read API. 

[0572] Event Configuration File (ECF) 

[0573] A text file, (possibly editable by the technician), 
which defines which events are to be logged locally on the 
AP and/or passed to the SNMP Agent for transmission to the 
element management system Server. Events that are 
required to be logged and passed to the element management 
system Server as defined by the system requirements will 
not be allowed to be changed. The ECF also allows the 
technician to set the X.733 values associated with alarms 
and informational messages. An ECF-checker apphcation 
(e.g. shewawk) will be written to prevent invahd modifica- 
tions to the file. 

[0574] ADMIN Log 

[0575] An ASCII file, written by the Event Handler, that 
contains events that are to be logged as defined by the ECF, 
with common fields in a fixed format. This file will be based 
on the existing OMP Admin logging mechanism.The fields 
for Alarm entries will match the content and order of the 
fields that appear on the element management system Server 
Alarm List application and will be tab delineated .The 
amount of data contained in the Event Log will be main- 
tained through the standard logfile mechanisms. Access to 
the Event Log will be through standard mechanisms (cut- 
through to the AP, use of a standard editor). 

[0576] EMAPI 

[0577] Overview 

[0578] The Element Management System (EMS) provides 
a framework for monitoring and controlUng network ele- 
ments. Each physical and logical component in the network 
is modeled as a managed object, which the Server makes 
visible to distributed client applications through the facilities 
of the Common Object Request Broker Architecture 
(CORBA). EM Clients need only be concerned about the 
attributes and operations defined for each application man- 
aged object, and not the details of network-level protocol 
and the server infrastructure required to support abject 
services. The following is the Element Management Appli- 
cation Programming Interface (EMAPI) 55 in accordance 
with the invention utilized by EM Clients. 

[0579] EMAPI Object Definitions 

[0580] FIG. 15 shows all of the interfaces visible to client 
applications: 

[0581] FIG. 15 does not depict process or processor 
boundaries, which are made transparent by the client and 
server object request brokers (ORBs). Application services 
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are provided through object interfaces formally defined in 
the CORBA Interface Definition Language (IDL). 

[0582] The service objects resident on the server with 
which client applications interact are shown in Tablelin FIG. 
16. 

[0583] Client applications which register for real-time 
status updates or notification of events, alarms or configu- 
ration changes must provide a reference to a local callback 
object which the Server will use to propagate information 
asynchronously. The callback interfaces defined in the 
EMAPI are listed in Table 2 shown in FIG. 17. Classes 
which implement these interfaces must be defined and 
instantiated in Client code, 

[0584] Data Representation 

[0585] There are several fundamental data types defined in 
the EMAPI, which fall into one of two categories shown in 
FIG. 18, 

[0586] Session Management 

[0587] Each EM Client session is logically associated with 
a login. Session identifiers are assigned by the EM Server 
when the client registers with the user session manager at 
initialization. Each Client application is logically associated 
with a session. Application identifiers are assigned by the 
Client. For the Element Manager Graphical User Interface, 
each "window" will be assigned a unique application id. 
Note that each Client is required to register a periodic 
heartbeat to validate for the Server that its associated session 
is still active. 

[0588] The UserSession service object provides the 
following interfaces: 

[0589] start 

[0590] This method must be invoked by a Client at 
initialization to register a new session. 

[0591] stop 

[0592] A Client invokes this method to notify the 
Server that the associated session is terminating, and 
that all resources utilized by any of the applications 
associated with the session should be released. 

[0593] stop Application 

[0594] A Client uses this method to notify the user 
session manager of termination of a single applica- 
tion, 

[0595] heartbeat 

[0596] This method must be invoked at least every 
UserSession: :HeartbeatPeriod seconds to avoid a tim- 
eout condition which, when detected by a Server audit, 
will result in the release of all resources utilized by any 
application associated with the respective session. 

[0597] Managed Objects 

[0598] A managed object (MO) is an abstract representa- 
tion of a physical or logical resource which may be managed 
by the EMS, such as a network element, maintenance unit or 
data link. The EM Server will implement one application- 
specific service object for each type of physical or logical 
resource to be managed. Each of these service objects 
defines a set of attributes which identify managed object 



properties, as well as the operations which may be per- 
formed on a specified managed object instance. (The deci- 
sion to provide access to instance information through a 
single "service object" stems from the fact that current ORB 
implementations become unstable when managing large 
numbers of remote references.) The diagram shown in FIG. 
19 depicts the relationship between Client, application- 
specific service object, and the internal Server representation 
of managed object instances. 

[0599] Each managed object service class is uniquely 
identified by a QassCodc. Each managed object instance is 
uniquely identified by an Instld. Any object instance in the 
system may be uniquely referenced by a managed object 
identifier (Oid), which is the combination of ClassCode and 
Instld 

[0600] Managed object status information is reported by a 
service object as a sequence of attribute code-value pairs. 
Each attribute value is defined as a union of all of the 
EMAPI fundamental data types described in the section 
herein pertaining to DATA 

[0601] Representation, 

[0602] Configuration information is reported as a 
sequence of ConfigData structures, which are defined to 
contain: 

[0603] network element instance id 

[0604] managed object instance id 

[0605] a managed object key list reported as a 
sequence of attribute-value pairs (when length is 
greater than 0, the key list usually specifies one or 
more Ijogicallds) 

[0606] Each managed object service class must implement 
the MO interface, which defines the following configuration 
and status services: 

[0607] viewConfig 

[0608] A client uses this method to obtain the current 
EMS view of the managed object configuration for a 
specified network element instance. Note that the 
reserved instance identifier Anylnstance may be used 
to obtain configuration information for all network 
elements. 

[0609] nodfyConfig 

[0610] A client may also register for managed object 
configuration information via callback. In this case, 
an initial view is returned with a notification type 
CONFIGJNIT. 

[0611] Subsequent changes arc reported with type 
CONFIG_CREATE or CONFIG^DELETE. 

[0612] cancelNotify 

[0613] A client uses this method to cancel registration 
for managed object configuration notifications asso- 
ciated with a specified client application, 

[0614] getPersistent 

[0615] A client may use this method to retrieve the 
set of attribute codes (SeqAttrCode) identifying all 
"persistent" data maintained by this service object. 
The associated attribute values for each managed 
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object instance are stored and kept current irrespec- 
tive of any client requests. 

[0616] viewStatus 

[0617] A client may invoke this method to obtain the 
EMS view of the current values for a specified set of 
persistent attributes for a specified managed object 
instance. 

[0618] getstatus 

[0619] A client may use this method to register for a 
snapshot of current status information. This interface 
differs from the previous one in that the requested 
attribute list may specify any managed object 
attribute codes — not just those associated with per- 
sistent data, and the information is returned via client 
status callback (StatusCB). 

[0620] startUpdate 

[0621] A client may also register for an initial view 
and notification of any updates to a list of selected 
attributes for a specified managed object instance. In 
this case, an initial view is reported via client call- 
back with a notification type STArUS_INIT Subse- 
quent changes are reported with type 
STATUS_CHANGE. Note that managed object 
instance deletions are reported only through configu- 
ration change notification (to avoid a potential flurry 
of client callbacks when a network element is 
unequipped). 

[0622] stopUpdate 

[0623] A client uses this method to cancel registration 
for managed object status updates. 

[0624] getlnst 

[0625] A client may use this method to obtain a 
managed object instance identifier for a specified 
network element instance id and managed object key 
list. 

[0626] Note that each method requires a client session 
application identifier (SessionAppId) to validate user access. 
In the case of configuration or status change notification 
registration, this identifier is also used to keep track of the 
additional server resources utilized while the client applica- 
tion is active, 

[0627] Network Element Level Managed Objects 

[0628] Each network-element level managed object must 
also implement the NEMO interface which defines addi- 
tional network-element level configuration services: 

[0629] viewNEconfig 

[0630] A client may invoke this method to obtain the 
current EMS view of the network element configu- 
ration. 

[0631] notifyNEconfig 

[0632] A client may also register for network ele- 
ment-level managed object configuration informa- 
tion via callback. In this case, an initial view is 
returned with a notification type CONFIG_INIT. 
Subsequent changes are reported with type CON- 
FIG_CREArE or CONnO^DELETE. 



[0633] canceNEnolify 

[0634] A client should use this method to cancel 
registration for network element managed object 
configuration updates. 

[0635] Note that each method requires a client session 
application identifier to validate user access. In the case of 
configuration change notification registration, this identifier 
is also used to keep track of the additional server resources 
utilized while the client application is active. 

[0636] Descriptive Entity Objects 

[0637] Application objects of this type are defined to 
provide type and attribute information for abstract entities, 
such as data communicated between the EMS and network 
elements which are not part of a managed object description 
(e.g. SNMP trap definitions and command groups). Descrip- 
tive entity objects provide no implementation-they are 
defined and known by cfient applications at compile time. 

[0638] Event Distributor 

[0639] An event is reported as a combination of the 
following: 

[0640] 1 . A header, which contains information of most 
general interest: 

[0641] Time of the event 

[0642] Event category defined to be one of the fol- 
lowing: 

[0643] Alarm Set 

[0644] Alarm Clear 

[0645] Command Acknowledgment 

[0646] Command Response 

[0647] Configuration Change 

[0648] Informational Message 

[0649] Initialization 

[0650] State Change 

[0651] Network element object identifier 

[0652] Network element alarm level (meaningful 
only for alarm set) 

[0653] Maintenance unit object identifier (if appli- 
cable) 

[0654] Maintenance unit alarm level (meaningful 
only for alarm set) 

[0655] A command identifier (Cmdld) defined as a 
user session id & command sequence number (mean- 
ingful only for command acknowledgment & 
response) 

[0656] 2. Event data defined as a sequence of structures 
which contain: 

[0657] A ClassCode of a managed object, network 
element or descriptive entity 

[0658] A sequence of attribute code-value pairs 

[0659] Client applications may request a copy of the event 
stream, as processed by the event distributor, filtered on 



08/19/2004, EAST version: 1.4.1 



us 2001/0052006 Al 



25 



Dec. 13, 2001 



information specified in the event header. Filter wildcards 
arc implemented with "out -of -band" values: 

[0660] Any Category 

[0661] Any Class 

[0662] Any Instance 

[0663] Any Alarm 

[0664] AnyCmd 

[0665] The Table 3 described in FIG. 20 summarizes 
which filter criteria are valid for each event category: 

[0666] The event distributor processes filters by examin- 
ing the specified category and AND'ing together valid 
criteria. Clients may simulate OR operations by registering 
multiple filters. 

[0667] The EviDist service object implements the 
following client interfaces: 

[0668] registerFilter 

[0669] A client uses this method to register an event 
filter. A filter identifier is returned. 

[0670] caacelFilter 

[0671] A client invokes this method to remove a 
specified event filter, using the filter id returned from 
the associated registration. 

[0672] Note that each method requires a client session 
application identifier to validate user access. 

[0673] Alarm Manager 

[0674] Alarm information is reported as a sequence of 
AlarmData structures which contain: 

[0675] The ClassCode of a managed object which 
defines a network-element specific alarm record. 
Note that in the first release of the EMS, only one 
network element active alarm table is defined 
(Ap ActiveAlarms) . 

[0676] A sequence of alarm records, each of which 
contains an alarm instance identifier and sequence of 
attribute code- value pairs. 

[0677] Client applications may request a copy of all active 
alarms filtered on any combination of the following: 

[0678] Network element 

[0679] Maintenance unit 

[0680] Alarm level 

[0681] Similar to the interfaces provided by the event 
distributor, out-of-band values may be used to represent 
wildcards. 

[0682] Since managed object instance information may 
not be available at the time an alarm is reported, the actual 
alarm filter criteria are specified in terms of logical identi- 
fiers. Logical IDS are integer values which represent the 
logical numbers of devices and interfaces (e.g. AP 4). The 
correlation between logical ids and managed object instance 
identifiers is provided in the configuration information made 
available by each managed object service object, and 
through the utility method getlnst. Refer to the section on 
Managed Objects for additional details. 



[0683] The AlarmManager client interfaces are written 
specifically for the Active Alarm List application: 

[0684] requestAlarms 

[0685] A client invokes this method to register a filter 
for active alarms. 

[0686] changePilter 

[0687] A client may invoke this method to change 
filter criteria. 

[0688] refireshAlarms 

[0689] A client may invoke this method to refresh the 
active alarm list. 

[0690] cancelAlarms 

[0691] A client should invoke this method to de- 
register a filter. 

[0692] All operations except for de-registration return all 
active alarms filtered on the specified criteria. Also, each of 
these methods requires a valid client session application 
identifier to validate user access, and to keep track of the 
additional server resources which may be utilized while each 
client is active. 

[0693] Exceptions 

[0694] Exceptions are used for consistent and structured 
error handling in both the EM Server and Client. 

[0695] The CORBA specification defines many system 



exceptions: 




[0696] 


BAD_PARAM 


[0697] 


INV_OBJREF 


[0698] 


NO^PERMISSION 


[0699] 


BAD_OPERATION 


[0700] 


NO_RESPONSE 


[0701] 


OBJ_ADAPTER 


[0702] 





[0703] Refer to "The Common Object Request Broker: 
Architecture and Specification" for an exhaustive list of 
mnemonics and the associated exception descriptions. 

[0704] Vendor-specific object request broker exceptions 
are also defined (using the Minor identifier of the Syste- 
mException): 

[0705] NO_IT_DAEMON_PORT 

[0706] LICENCE_EXPIRED 

[0707] 

[0708] Cuncntly, the EMS uses lona's Orbix product. 
Refer to the "Orbix 2.1 Reference Guide" for an exhaustive 
List of mnemonics and the associated exception descriptions. 

[0709] In FIG. 21 an EMAPI-specific exception is 
defined, with an EmapiExceptionCode containing one of a 
plurality of values. 

[0710] In most cases, exceptions will be treated as fatal 
errors by a Qient resulting in termination of all associated 
applications. 
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[0711] Those skilled in the art who now have the benefit 
of the present disclosure will appreciate that the present 
invention may take many forms and embodiments. Some 
embodiments have been presented and described so as to 
give an understanding of the invention. It is intended that 
these embodiments should be illustrative, and not limiting of 
the present invention. Rather, it is intended that the invention 
cover all modifications, equivalents and alternatives falling 
within the spirit and scope of the invention as defined by the 
appended claims. 

APPENDIX A 

[0712] Definition of Terms 

[0713] Alarm A condition, usually of an unexpected 
nature, which requires special and persistent technician 
notification. 

[0714] Active Alarm A JAVA applet displaying the 
ctirrent active alarms in the system for all 

[0715] List Browser managed objects, A sample Active 
Alarm List Browser Applet can be found 

[0716] Applet in Attachment 2 on the Alarms Web Page. 

[0717] ASN.l Abstract Syntax Notation One: A formal 
language used to define syntax. In the case of SNMP, 
ASN.l notation is used to define the format of SNMP 
protocol data units and of objects. 

[0718] AP Application Processor refers to a commercial 
computing system that provides generic computing 
facilities. 

[0719] APCC Application Processor Cluster Complex: 
the highly-available platform, or cluster computing 
environment, in which an AP in the cluster can run the 
application services of another AP in the cluster should 
that AP fail. 

[0720] AP EMS The OA&M software architecture 
components that reside on the AP to 

[0721] Infrastructure support the APCC OA&M archi- 
tecture. These include the MIB on the AP, the SNMP 
agent on the AP, the event handler, and other compo- 
nents described in section 4 of this document. 

[0722] API Application Programming Interface: a well- 
defined software interface, usually abstracting the 
details of the underlying implementation from the 
client of the interface. 

[0723] Applet small Java program which is dynamically 
downloaded by a Web browser and executed by its 
virtual machine. Though a Java applet has access to 
many of the services provided by the browser execution 
environment (e.g. audio, network access), it is also 
restricted by the browser Security Manager (e.g. no 
access to local file system). 

[0724] Attribute A property of a managed object. An 
attribute has a value. 

[0725] Attribute Code A code that identifies a specific 
attribute of a managed object class. 

[0726] Class Code An integer value which uniquely 
identifies a managed object class. 

[0727] Client A function passed by the client to the 
server that is used by the server to 



[0728] Callback deliver asynchronous notifications of 
attribute changes, configuration changes 

[0729] Function or event notifications. 

[0730] Client/Server A type of distributed computing 
architecture. 

[0731] Client An X-TerminallWorkstation or Windows 
95 PC that can host the EMS client 

[0732] Terminal applications. These Client Terminals 
are commonly referred to as a Client Application 
Workstation. 

[0733] CMU SNMP Carnegie Mellon University 
SNMP Library that can used to create a SNMP 

[0734] Library manager and a SNMP agent. 

[0735] Command A "short" reply to a command to 
indicate whether the command was rejected, 

[0736] Acknowledgm executed, or is in progress. 

[0737] ent 

[0738] Command "Lengthier" replies to a command, 
giving the results of executing the 

[0739] Response command. A command may have mul- 
tiple responses. 

[0740] Configuration Data of a non-transient nature. 
This is data that is provisioned by the 

[0741] Data technician (e.g. via Recent Change and 
Verify at the ECP), as opposed to data associated with 
the operation/execution of a managed object. 

[0742] Configuration Generic term which has one of 
two meanings depending on its context: 

[0743] Information 

[0744] With respect to a managed object class, this 
term applies to the identification of all instances of 
the class, either for a specific network element or for 
all network elements in the system. 

[0745] With respect to a managed object instance, 
this term may apply to one or more attributes which 
are associated with database values, such as the 
primary/alternate role of a duplex component. 

[0746] Containment A structuring relationship for man- 
aged object instances in which the existence of a 
managed object instance is dependent on the existence 
of a containing managed object instance. An example is 
the RCS object contained within the AP object. 

[0747] CORBA Common Object Request Broker Archi- 
tecture: A specification authored by the Object Man- 
agement Group, a consortium of more than 600 com- 
panies, for producing interoperable applications that 
are based on distributed, interope rating objects. 

[0748] Element Manages network elements. In the ini- 
tial releases of PlanR, management is 

[0749] Management limited to fault management. 

[0750] System 

[0751] Element A term used to encompass the OA&M 
infrastructure components that do not 



08/19/2004, EAST Version: 1.4.1 



us 2001/0052006 Al 



27 



Dec. 13, 2001 



[0752] Management reside on the managed element 
(see AP EMS Infrastructure). 

[0753] System Server 

[0754] EMAPI Element Management Application Pro- 
gramming Interface 

[0755] Event Generally, an autonomous notification. 
We have defined four types of events that the AP can 
generate: alarms, reports, state changes, configuration 
changes. 

[0756] IS-634 An international standard suite that 
defines the interfaces required to attach base stations 
from one vendor to the MSG of another vendor. 

[0757] IDL Interface Definition Language: A C++-like 
notation for describing CORBA object interfaces, IDL 
is used to describe any resource or service a server 
component wants to expose to its clients without regard 
to its implementation language or operating system 

[0758] Inheritance The conceptual mechanism by 
which attributes, notifications, operations, and behavior 
are acquired by a subclass from its superclass. 

[0759] Instance An integer value that identifies a spe- 
cific instance of a managed object and is 

[0760] Identifier unique within its managed object class. 

[0761] JAVA An object oriented programming language 
from Sun Microsystems that is interpreted, allowing 
applications to run on many platforms without change. 

[0762] Logical An integer value which represents the 
logical number of a device or interface 

[0763] Identifier (e.g., AP4). Note that there is no direct 
correlation between a logical id and instance id. 

[0764] Managed An abstract representation of a 
resource that may be managed by the network 

[0765] Object management platform. Examples include 
a network element, a maintenance unit, network ele- 
ment summary, datalink. 

[0766] Managed A named set of managed objects that 
share the same sets of attributes, 

[0767] Object Class notifications and management 
operations. An example is the AP managed object class. 

[0768] Managed A code that identifies a specific man- 
aged object class (tmique to the system). 

[0769] Object Class This code is a constant (enumera- 
tion or integer definition). 

[0770] Code 

[0771] Managed The combination of managed object 
class code and instance identifier defines 

[0772] Object the managed object identifier. Also abbre- 
viated as an MOID. 

[0773] Identifier 

[0774] Method or An operation or method on a man- 
aged object performs an action. 

[0775] Operation 

[0776] MIB Management Information Base: a data defi- 
nition of Network Element objects to be managed by a 



Element Manager, written in an Internet-standard lan- 
guage, specific to the SNMP protocol. 

[0777] MMA Message Mapping Application: the appli- 
cation which maps between the Autoplex Base Station 
Interface (ABI) call state and message sequence and the 
IS-634 call state and message sequence. MMA is 
sometimes referred to as Open A Interface (OAI). 

[0778] Network A functional component of the 
Autoplex system such as a cell site, 

[0779] Element Application Processor (AP), Call Pro- 
cessing Data Node (CDN), Executive Cellular Proces- 
sor (ECP). 

[0780] Network A JAVA applet depicting detailed status 
on the managed objects belonging to 

[0781] Element the network element. A sample view of 
the Network Element Detailed Status 

[0782] Detailed Applet can be found in Attachment 2 on 
the AP Web Page. 

[0783] Status Applet 

[0784] Network Managed object attributes and their 
corresponding values that represent the 

[0785] Element Status status of the NE. The PlanR 
APCC NE status consists of status for the RCS-AP, and 
IS-634-AP managed objects, an active alarm list, and a 
table of outstanding commands. 

[0786] Notification Information sent by an agent to a 
manager when an event occurs at the associated net- 
work element. This includes alarmed and informational 
messages, notification of configuration changes within 
the network element, as well as acknowledgments to 
technician input commands. 

[0787] OAI AP An AP running the OAI application. 

[0788] ORB Object Request Broker 

[0789] Object The combination of managed object class 
code and instance identifier which 

[0790] Identifier uniquely identifies any managed object 
instance in the system. 

[0791] Persistent Information stored and kept current 
irrespective of any client requests (e.g., 

[0792] Attribute maintenance state). 

[0793] RAP API A general API for spawning a process 
and obtaining the results of the process execution. 
Generally, RAPs will be used to carry out a mainte- 
nance command on an AP resource. RAPs may spawn 
other processes, if necessary. 

[0794] RCC Reliable Cluster Computing. A Highly- 
Available (HA) product from Lucent Technologies that 
provides the software and hardware components to 
enhance the reliability, availability and maintainability 
of a HA or clustered system. 

[0795] RCS Radio Cluster Server, The application runs 
on the AP to provide call processing and OA&M 
functionality for the PlanR microcell. The software for 
this application is ported from the Radio Cluster Con- 
troller of a Series II cell. 
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[0796] RCS AP The AP that hosts the RCS application. 

[0797] Service Object The object that provides services 
for a managed object class. Client applications acquire 
a reference to this object (in CORBA they bind to the 
object). An example is the AP service object and the 
Session service object. 

[0798] Session Each client must establish a unique 
session that is used to validate access permissions and 
for subsequent routing of notifications. 

[0799] SNMP Simple Network Management Protocol: 
an Internet-standard protocol for managing Network 
Elements from a Network Manager; provides three 
basic operations: GET, SET, and TRAP (autonomous 
notification). 

[0800] SNMP Agent The Software entity that resides on 
the Network Element and interfaces to the Network 
Manager via the SNMP protocol. This process listens 
on a specific UDP port in order to receive SNMP 
requests from the Manager and forwards TRAPs from 
the NE to the Manager. 

[0801] SNMP Trap An autonomous notification from 
the Network Element to the Network Manager. 

[0802] State Change A change in one or more of the 
atU-ibutes associated with a managed object. 

[0803] Status Current attribute values for a managed 
object instance. 

[0804] Information 

[0805] System A JAVA applet that displays a summary 
of the status of all network elements 

[0806] Summary in the system. In Attachment 2, an 
example of the System Summary Applet 

[0807] Applet can be found on the Network Web Page. 

[0808] TVOP Technician Interface and Output Proces- 
sor. The Autoplex subsystem where input commands 
and output reports are handled. 

[0809] X Terminal A type of client terminal that only 
displays the X protocol and can not host the EMS client 
applications. Instead, the client applications run on the 
Server and arc displayed (via the X protocol) on the X 
terminal. 

[0810] Glossary of Acronyms 

[0811] 1. GLOSSARY 

[0812] ACF Agent Configuration File 

[0813] AP Application Processor 

[0814] APCC Application Processor Cluster Complex 

[0815] API Application Programming Interface 

[0816] ASN.l Abstract Syntax Notation One 

[0817] C/S Client/Server 

[0818] CDPD Cellular Digital Packet Data 

[0819] CD-ROM Compact Disk — Read Only Memory 

[0820] CHAP Command Handler Access Point 



[0821] CMIP Common Management Information Pro- 
tocol 

[0822] COGS Cost of Goods 

[0823] CORBA Common Object Request Broker Archi- 
tecture 

[0824] DAT Digital Audio Tape 

[0825] DCI Digital Computer Interface 

[0826] DELPHI Desktop Wuidows Visual Develop- 
ment Tool from Borland 

[0827] EAI Emergency Action Interface 

[0828] El Emergency Interface 

[0829] ECF Event Configuration File 

[0830] ECP Executive Control Processor 

[0831] ECPC Executive Control Processor Complex 

[0832] EIN Ethernet Interface Node 

[0833] EMAPI Element Management Application Pro- 
gramming Interface 

[0834] EMS Element Management System 

[0835] FTP File Transfer Protocol 

[0836] GUI Graphical Client Interface 

[0837] HA High Availability 

[0838] HA-OMP High Availability Operations and 
Management Platform 

[0839] HP Hewlett Packard 

[0840] HPOV HP Open View 

[0841] HPOVNNM HP OpenView Network Node 
Manager 

[0842] HTML HyperText Markup Language 

[0843] HTTP Hypertext Transfer Protocol 

[0844] ICMP Internet Control Message Protocol 

[0845] IDL Interface Definition Language 

[0846] IDS internal database subsystem 

[0847] IP Internet Protocol 

[0848] ipmap HPOVNNM component used to monitor 
up/down status of network elements 

[0849] JAR JAVA Archive 

[0850] LAN Local Area Network 

[0851] LMT Local Maintenance Terminal 

[0852] Mbytes Megabytes 

[0853] MEB Management Information Base 

[0854] MMA Message Mapping Application 

[0855] MO Managed Object 

[0856] MOID Managed Object Identifier 

[0857] NE Network Element 

[0858] NEST Network Element Status Table 
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14. The method of claim 1 in which the computer internet 
is the world wide web and the steps of connecting and 
coupling include the step of operating world wide web based 
JAVA applications at the management computer and the 
element management server. 

15. The method of claim 1 in which the network clement 
has a management agent application which responds to 
various actions and the step of managing includes the step of 
correlating responses from the agent with the actions which 
caused the actions. 

16. The method of claim 1 in which the step of managing 
includes the step of automatically routing conamand 
responses, polling results and traps back to the management 
computer. 

17. The method of claim 1 in which 

the network element has a management agent application, 
and including the steps of 

queuing multiple commands simultaneously received 
from a plurality of different management computers 
including the one management computer, and 

successive responding to the multiple commands by send- 
ing reponses to appropriated ones of the different 
management computers that originated the commands, 
respectively. 

18. The method of claim 1 in which the step of connecting 
includes the step of enabling the connection in response to 
entry of a correct password at the management computer. 

19. The method of claim 18 including the step of encrypt- 
ing the password prior to sending to the management server. 

20. The method of claim 1 in which the step of managing 
includes the steps of 

selecting network element attributes from a plurality of 
network element attributes available for polling, and 

polling for only the selected network element attributes. 

21. The method of claim 1 in which the step of managing 
includes the steps of 

receiving requests at the network element from a plurality 
of different management computers to poll for network 
element attributes which are the same, 

polling for the attributes which are the same only as if 
there were only one request for polling of the same 
attributes, and 

providing the results of the polling of the same attributes 
to all of the different management computers that 
requested polling of the same attributes. 

22. The method of claim 1 including the step of auto- 
matically updating a list of active alarms of the network 
element upon occurrence of either one of actuation of a new 
alarm and clearing of a former alarm. 

23. In a communication network having a plurality of 
network elements, a method for managing the network 
clement, comprising the steps of: 

selectively running a management application at a plu- 
rality of different work station for command, control 
and fault management of the network element; 

interfacing an element management server through a 
computer internet to the plurality of different work 



stations to provide distributed network element man- 
agement services to the client application at all of the 
plurality of work stations; and 

interfacing the network element with the element man- 
agement server through a management agent applica- 
tion associated with the network element for commu- 
nicating command acknowledgment and command 
requests through the computer internet between the 
network management server and the network clement. 

24. The method of claim 23 in which the element man- 
agement server includes an object server having managed 
objects representing the network element and other 
resources of the system. 

25. The method of claim 23 in which the step of com- 
municating command acknowledgment and command 
request between the element management server and the 
network element is conducted using a simple node manage- 
ment protocol. 

26. The method of claim 23 in which the step of com- 
municating includes the steps of 

establishing a set of SNMP service objects that commu- 
nicate with the SNMP network element; 

establishing a SNMP mediator process that communicates 
with the SNMP service objects; 

polling for the SNMP service objects; and 

converting commands of the managed object to SNMP set 
commands. 

27. The method of claim 23 including the step of filtering 
events of the network element. 

28. The method of claim 27 in which the events of the step 
of filtering events includes at least one of the events of alarm 
notification, state change and configuration change to the 
element network system server. 

29. The method of claim 23 in which the step of inter- 
facing the network element includes the step of maintaining 
within the element management server a list of current 
active alarms within the network. 

30. The method of claim 23 including the steps of 

monitoring the operation of events within the communi- 
cation network, and 

diminishing the operation of events to prevent overload- 
ing of the communication system. 

31. The method of claim 23 in which 

the management application is written in JAVA, and 

the step of interfacing the work stations with the element 
management server is performed through an interactive 
web page that visually displays a menu of command, 
control and fault management options. 

32. The method of claim 31 in which the web page 
includes a separate status summary display for each of the 
command, control and fault management options. 

33. The method of claim 3 in which the web page includes 
a display of a list of active alarms for all network elements 
within the communication network. 

* ♦ ♦ * * 
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